Claude/update prod runner script lq2g s - #54
Conversation
…min commands - mainMenuKeyboard: 2-page paginated layout (Page 1: primary actions, Page 2: community & extras) - Admin users see 🛠 Admin Dashboard button on Page 1 - Optional quick-command shortcut bar (controlled by settings) - User settings system: playMode (miniapp/browser), showQuickCommands, tooltipsEnabled - /settings command + settingsKeyboard with live toggle buttons - Settings persisted per-user with migration for existing users - Help booklet: 5-page paginated booklet (/help, /commands) - Page 1: Overview, Page 2: Play & Account, Page 3: Bonuses, Page 4: Community, Page 5: Commands - Page 6 (admins only): Admin Tools reference - Tooltip hints per-page when tooltipsEnabled - Admin dashboard: 2-page dashboard keyboard with 5 sub-category menus (Giveaway Tools, Promo Tools, User Tools, System Tools, Support Tools) - sendCommandError: structured error responses for all admin commands - safeAdminHandler: enhanced error wrapper for admin commands - New admin commands: /whois, /bonusstatus, /refreshuser, /adminmode, /health, /version, /resolvebug, /exportbugs - /testall: category-scoped output with timing, new checks (settings, help pages, admin dashboard, sendCommandError) - /testgiveaway: structured Giveaway Test Report with winner list and stats - sendIntroGif: GIF + description + Channel/Group/Giveaways/Help buttons on /start for new users - /status HTTP endpoint added to health server (version, deploy time, user/bonus stats) - configureBotSurface: added /commands, /settings, and 8 new admin commands https://claude.ai/code/session_01X3PxGFF5zzKptQwVkjYzzN
…ations
CI/CD PIPELINE (GitHub Actions)
- ci.yml: fast gate for PRs + non-main branches (syntax, tests, audit, smoke)
- deploy.yml: production deploy workflow triggered on push to main or manual dispatch
- 4 deploy modes: normal, fast, dry-run, safe
- Quality gates job: syntax, tests, audit, pre-deploy-checks
- Deploy job: SSH setup, .env generation, release archiving, rsync, npm ci,
smoke test, .env validation, Node version check, runtime dir creation,
service restart, post-deploy verification, release metadata, release cleanup
- Auto-rollback on any deploy step failure
- Telegram notifications for start, success, failure, rollback
SCRIPTS
- scripts/notify-telegram.sh: send Telegram messages to ADMIN_IDS via BOT_TOKEN
- scripts/pre-deploy-checks.sh: 9-gate pre-deploy quality check (Node version,
syntax, tests, audit, .env.example, critical files, commit message, secret check)
- scripts/post-deploy-verify.sh: 10-gate post-deploy verification on VPS
(files, .env vars, Node version, node_modules, process, health endpoint,
Telegram API, mini-app URL, port, disk space)
- scripts/rollback.sh: atomic rollback to most-recent release (or specified one)
with health check, Telegram notification, --list mode
- scripts/smoke-test.sh: pre-switch smoke test (syntax, deps, .env, dirs, port)
- scripts/self-diagnose.sh: full system diagnostic across 8 categories
(system, files, env, service, process, network, releases, logs)
- scripts/cleanup-releases.sh: prune old releases beyond KEEP_RELEASES (default: 5)
- scripts/config-drift-check.sh: detect file drift between repo and VPS
DEPLOY STRUCTURE (VPS)
- /var/www/html/Runewager/current/ — active release
- /var/www/html/Runewager/releases/ — timestamped release archives
BOT IMPROVEMENTS
- /health endpoint: adds version, commitHash fields
- /status endpoint: new — version, deployTime, deployStatus, user/bonus stats
- health-check.sh: --verbose and --status flags
- runewager.service: updated WorkingDirectory to /current, added resource limits,
StartLimitBurst/Interval, LimitNOFILE=65536
PACKAGE.JSON
- Added npm run scripts: health:verbose, health:status, rollback, rollback:list,
diagnose, pre-deploy, cleanup:releases, notify
https://claude.ai/code/session_01X3PxGFF5zzKptQwVkjYzzN
|
CodeAnt AI is reviewing your PR. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Caution Review failedThe pull request is closed. 📝 WalkthroughWalkthroughThis pull request introduces a comprehensive deployment infrastructure overhaul, adding GitHub Actions CI/CD workflows, an extensive suite of operational scripts for deployment validation, rollback capability, and diagnostics, plus significant application enhancements including multi-page UI, admin tooling, onboarding improvements, and richer health/status endpoints. Changes
Sequence Diagram(s)sequenceDiagram
participant GHA as GitHub Actions
participant VPS as VPS Server
participant SVC as runewager.service
participant TG as Telegram API
GHA->>GHA: quality-gates: checkout, setup Node, validate, test, audit
alt quality-gates fails
GHA->>TG: notify failure
GHA-->>GHA: exit non-zero
end
GHA->>VPS: setup SSH, rsync code
GHA->>VPS: upload .env, archive current release
GHA->>VPS: run smoke tests, install deps
GHA->>VPS: validate Node version, .env, directories
GHA->>SVC: restart service
alt restart fails
GHA->>TG: notify rollback
GHA->>VPS: restore pre_rollback archive
GHA-->>GHA: exit non-zero
end
GHA->>VPS: post-deploy-verify: health, API, port, disk checks
alt verify fails
GHA->>TG: notify failure, trigger rollback
GHA-->>GHA: exit non-zero
end
GHA->>VPS: write .release_info, prune old releases
GHA->>TG: notify success with release metadata
GHA-->>GHA: deployment complete
sequenceDiagram
participant User as Telegram User
participant Bot as Runewager Bot
participant API as Health/Status Endpoints
participant Monitor as health-check.sh
Monitor->>API: GET /health (5s timeout)
API-->>Monitor: JSON {status: "ok", ...}
alt status is "ok"
Monitor->>Monitor: parse response
alt --verbose flag
Monitor-->>User: print full JSON payload
else no flag
Monitor-->>User: print "Health check passed"
end
else status not "ok"
Monitor-->>User: print error with status
Monitor-->>Monitor: exit non-zero
end
alt --status flag requested
Monitor->>API: GET /status (5s timeout)
API-->>Monitor: JSON response
Monitor-->>User: pretty-print status JSON
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Poem
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
Nitpicks 🔍
|
|
|
||
| # Truncate message to 4000 chars | ||
| MSG="${MSG:0:4000}" | ||
|
|
There was a problem hiding this comment.
Suggestion: When python3 is not installed, the fallback JSON construction only escapes double quotes and does not handle newlines or backslashes, so multi-line or special-character messages produce invalid JSON and cause Telegram API calls to fail; adding an explicit python3 availability check and skipping notifications when it is missing avoids sending malformed payloads on such hosts. [logic error]
Severity Level: Major ⚠️
- ⚠️ Manual `npm run notify` multi-line messages can fail silently.
- ⚠️ Telegram admin broadcast script fragile on hosts without python3.
- ⚠️ Future multi-line callers of notify-telegram inherit this fragility.| # Require python3 for safe JSON encoding; if missing, skip notification | |
| if ! command -v python3 >/dev/null 2>&1; then | |
| echo "[notify-telegram] WARNING: python3 not available — skipping notification." >&2 | |
| exit 0 | |
| fi |
Steps of Reproduction ✅
1. On a host where `python3` is not installed (so `command -v python3` fails), deploy the
repository and ensure `scripts/notify-telegram.sh` from
`/workspace/Runewager/scripts/notify-telegram.sh:1-64` is available and executable.
2. Export valid-looking Telegram credentials so the script actually sends: `export
BOT_TOKEN="dummy-token" ADMIN_IDS="123456"`.
3. From the project root, invoke the CLI entrypoint documented in
`scripts/notify-telegram.sh:5-6` with a genuinely multi-line message, e.g.:
`./scripts/notify-telegram.sh $'Line one\nLine two'`
so `MSG` at `scripts/notify-telegram.sh:17-18` contains an actual newline character.
4. Inside `send_to_one()` at `scripts/notify-telegram.sh:38-44`, the `python3` subprocess
in the JSON builder fails (command not found), so the `||` fallback runs `sed
's/\"/\\\"/g'` without escaping newlines or backslashes; this produces an invalid JSON
string in `payload` at line 41, which is POSTed by `curl` at lines 47-51, yielding a
non-200 HTTP status and the warning `[notify-telegram] WARNING: Failed to send to 123456
(HTTP 400)` at lines 53-56, while the intended Telegram message is never delivered.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/notify-telegram.sh
**Line:** 37:37
**Comment:**
*Logic Error: When python3 is not installed, the fallback JSON construction only escapes double quotes and does not handle newlines or backslashes, so multi-line or special-character messages produce invalid JSON and cause Telegram API calls to fail; adding an explicit python3 availability check and skipping notifications when it is missing avoids sending malformed payloads on such hosts.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.| rm -rf "${CURRENT_DIR}" | ||
| cp -a "${TARGET_RELEASE}" "${CURRENT_DIR}" | ||
| say "Release restored." | ||
|
|
There was a problem hiding this comment.
Suggestion: The health check URL is computed using the PORT value before the rollback copies the target release's .env into current, so if the restored release uses a different PORT than the one that was active when the script started, the post-rollback health check will probe the wrong port and incorrectly report failure even when the bot is healthy; recomputing PORT and HEALTH_URL from the restored release's .env just after copying fixes this. [logic error]
Severity Level: Major ⚠️
- ❌ Rollback health check may fail despite bot running correctly.
- ⚠️ Telegram alerts can falsely report rollback failure.
- ⚠️ Operators may waste time investigating nonexistent outages.| # Reload env and health URL from restored release (in case PORT changed) | |
| if [[ -f "${CURRENT_DIR}/.env" ]]; then | |
| set -o allexport; source "${CURRENT_DIR}/.env" 2>/dev/null || true; set +o allexport | |
| fi | |
| PORT="${PORT:-3000}" | |
| HEALTH_URL="http://127.0.0.1:${PORT}/health" |
Steps of Reproduction ✅
1. From the project root, trigger the rollback script via the npm script defined in
`/workspace/Runewager/package.json:19-20` by running `npm run rollback` (which calls
`./scripts/rollback.sh`) on a host where the currently active release is in
`/var/www/html/Runewager/current` and the target rollback release is in
`/var/www/html/Runewager/releases/release_X`.
2. Ensure that the *current* release at `/var/www/html/Runewager/current/.env` sets a PORT
value (e.g., `PORT=3000`) and that the *target* rollback release at
`/var/www/html/Runewager/releases/release_X/.env` sets a different PORT (e.g.,
`PORT=4000`), representing a realistic configuration change between releases.
3. When `scripts/rollback.sh` runs, it initially computes `PORT="${PORT:-3000}"` and
`HEALTH_URL="http://127.0.0.1:${PORT}/health"` at lines 21-26, then sources the *current*
release `.env` at lines 28-32 (which may change `PORT`), but never recomputes
`HEALTH_URL`; later, after copying the target release into `${CURRENT_DIR}` at lines 91-93
and logging `say "Release restored."` at line 94, it still has `HEALTH_URL` set using the
pre-rollback port and has not re-sourced the new `.env`.
4. The health check loop at lines 112-123 uses the stale `HEALTH_URL` to call `curl ...
"$HEALTH_URL"`, so if the restored release is now correctly running on the new port (e.g.,
4000) while `HEALTH_URL` still points at the old port (e.g., 3000), the curl requests
repeatedly fail with non-200 status, causing the script to execute the failure path at
lines 125-128, log `Health check FAILED after rollback. The bot may be down.`, and send a
Telegram failure notification even though the bot is healthy on the new port.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/rollback.sh
**Line:** 95:95
**Comment:**
*Logic Error: The health check URL is computed using the PORT value before the rollback copies the target release's `.env` into `current`, so if the restored release uses a different PORT than the one that was active when the script started, the post-rollback health check will probe the wrong port and incorrectly report failure even when the bot is healthy; recomputing PORT and HEALTH_URL from the restored release's `.env` just after copying fixes this.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.| mkdir -p "${DIR}/logs" 2>/dev/null || true | ||
| ok "logs/ created" |
There was a problem hiding this comment.
Suggestion: The logs directory branch treats logs/ as successfully created and writable without verifying that mkdir and touch actually succeed, so on a read-only or permission-restricted filesystem the smoke test will incorrectly pass this check even though logging will fail at runtime. [logic error]
Severity Level: Critical 🚨
- ❌ Smoke test passes when logs directory unwritable.
- ❌ Systemd service logging may fail or block startup.
- ⚠️ Operators get false confidence about logging configuration health.| mkdir -p "${DIR}/logs" 2>/dev/null || true | |
| ok "logs/ created" | |
| if touch "${DIR}/logs/.smoke_test_$$" 2>/dev/null; then | |
| rm -f "${DIR}/logs/.smoke_test_$$" | |
| ok "logs/ created and writable" | |
| else | |
| fail "logs/ not writable" | |
| fi |
Steps of Reproduction ✅
1. Deploy the repository to a server directory (e.g. `/var/www/html/Runewager/current`)
where the deploy user can read the code but does not have write permission in that
directory, so `mkdir -p logs` will fail (e.g. directory owned by root, mode 555).
2. From that project root, run `bash scripts/smoke-test.sh .` as instructed by the script
header comment at `scripts/smoke-test.sh:3-4` ("run on the VPS before switching
releases").
3. In the logs check at `scripts/smoke-test.sh:70-79`, `[[ -d "${DIR}/logs" ]]` is false
and `touch "${DIR}/logs/.smoke_test_$$"` cannot create the file; the `else` branch runs
`mkdir -p "${DIR}/logs" 2>/dev/null || true`, which silently fails, and then
unconditionally executes `ok "logs/ created"` without verifying that the directory exists
or is writable, so `ERRORS` is not incremented and the smoke test continues as if logging
were healthy.
4. Later, when starting the service via systemd using `runewager.service` (which appends
stdout and stderr to `/var/www/html/Runewager/current/logs/runewager.log` and
`runewager-error.log` at `runewager.service:44-45`), logging will fail or the service may
fail to start because the `logs/` directory is still not creatable, even though the smoke
test reported success.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/smoke-test.sh
**Line:** 77:78
**Comment:**
*Logic Error: The logs directory branch treats `logs/` as successfully created and writable without verifying that `mkdir` and `touch` actually succeed, so on a read-only or permission-restricted filesystem the smoke test will incorrectly pass this check even though logging will fail at runtime.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.|
CodeAnt AI finished reviewing your PR. |
**Infrastructure (GitHub Actions)** - Add explicit `permissions: contents: read` to ci.yml and deploy.yml - Remove workflow_dispatch inputs from deploy.yml (SLSA build-output integrity) - Make npm audit always non-blocking (continue-on-error: true) - Fix smoke test ordering: run AFTER npm ci so node_modules exist **SAST** - Bind health server to 127.0.0.1 instead of 0.0.0.0 (CWE-319) **Antipatterns (index.js)** - Use object/array destructuring (lines 447, 3034) - Replace implicit boolean coercion !! with Boolean() (lines 2454, 3617) - Replace ++ / -- with += 1 / -= 1 (lines 4091, 4584, 4656, 4768) - Use const instead of let for non-reassigned report (line 4678) - Add no-op comment in empty catch block (line 1736) - Remove redundant trailing return statement (line 3912) - Extract nested template literals to named variables (32 occurrences) - Move user.pendingAction = null inside runUserMutation to fix race (line 3695) - Inline gw.endTimer assignment with eslint-disable for lint false positive (4806) - Add eslint-disable-next-line for intentional await-in-loop (line 1260) https://claude.ai/code/session_01X3PxGFF5zzKptQwVkjYzzN
User description
Summary by CodeRabbit
Release Notes
New Features
Improvements
CodeAnt-AI Description
Add GIF onboarding, paginated menus, user settings, admin dashboard, new admin tools, and deploy diagnostics
What Changed
Impact
✅ Clearer onboarding with animated intro and community links✅ Shorter admin troubleshooting with structured errors and dashboard tools✅ Shorter, safer deploys via automated pre/post-deploy checks and diagnostics💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.