feat: scripts + docker-compose for local demo stack - #5
Conversation
🤖 CodeAnt AI — Review Status
|
codeant-ai
Bot
added
the
size:L
|
Failed to generate code suggestions for PR |
PR Summary by QodoAdd local demo stack orchestration scripts and Docker Compose
AI Description
Diagram
High-Level Assessment
Files changed (6)
|
Code Review by Qodo
1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| if (-not (Test-Command "node")) { Write-Error "node 18+ is required. Install from nodejs.org."; exit 1 } | ||
| $python = if (Test-Command "python") { "python" } elseif (Test-Command "py") { "py" } else { $null } | ||
| if (-not $python) { Write-Error "python 3.10+ is required."; exit 1 } |
There was a problem hiding this comment.
Suggestion: The prerequisite checks only verify that node and Python commands exist, despite claiming to require Node 18+ and Python 3.10+. Older interpreters pass this step and can fail later during dependency installation or service startup, so compare the detected versions against the stated minimums before continuing. [api mismatch]
Severity Level: Major ⚠️
- ⚠️ Unsupported Node.js reaches dashboard installation.
- ⚠️ Unsupported Python reaches infrastructure startup.
- ⚠️ Setup diagnostics contradict actual requirements.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/setup.ps1
**Line:** 17:19
**Comment:**
*Api Mismatch: The prerequisite checks only verify that `node` and Python commands exist, despite claiming to require Node 18+ and Python 3.10+. Older interpreters pass this step and can fail later during dependency installation or service startup, so compare the detected versions against the stated minimums before continuing.
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.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| echo "" | ||
|
|
||
| echo "[3/6] Building and starting demo infrastructure + MCP server..." | ||
| $DOCKER_COMPOSE up -d --build postgres redis demo-infra-mcp |
There was a problem hiding this comment.
Suggestion: The Compose build is guaranteed to fail on a clean checkout because demo-infra-mcp uses mcp-servers/demo-infra as its build context, but that directory contains no Dockerfile or server implementation. The setup therefore cannot reach the health check or start the documented stack; include the service files in the checkout or use the correct existing build context. [incomplete implementation]
Severity Level: Critical 🚨
- ❌ Clean setup cannot build `demo-infra-mcp`.
- ❌ MCP health check never succeeds.
- ❌ Local incident demo stack cannot start.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/setup.sh
**Line:** 37:37
**Comment:**
*Incomplete Implementation: The Compose build is guaranteed to fail on a clean checkout because `demo-infra-mcp` uses `mcp-servers/demo-infra` as its build context, but that directory contains no `Dockerfile` or server implementation. The setup therefore cannot reach the health check or start the documented stack; include the service files in the checkout or use the correct existing build context.
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.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| $litUp = ($LASTEXITCODE -eq 0) | ||
| $out = wsl -e bash -lc "curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:4000/v1/models --max-time 3" | ||
| if ($out -ne "200") { | ||
| wsl -e bash -lc "setsid -f -- /home/aditya/tf-litellm.sh </dev/null > /home/aditya/litellm.log 2>&1" |
There was a problem hiding this comment.
Suggestion: When either service is not already running, this startup path invokes user-specific files under /home/aditya; those files are not part of the repository and will not exist for another Windows user or a clean installation. The script then continues as though startup is supported, so derive these paths from repository configuration or invoke the checked-in setup/runtime commands instead. [api mismatch]
Severity Level: Critical 🚨
- ❌ Other Windows users cannot start LiteLLM.
- ❌ TrueForge startup fails on clean installations.
- ❌ One-command startup is not portable.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/start-all.ps1
**Line:** 38:38
**Comment:**
*Api Mismatch: When either service is not already running, this startup path invokes user-specific files under `/home/aditya`; those files are not part of the repository and will not exist for another Windows user or a clean installation. The script then continues as though startup is supported, so derive these paths from repository configuration or invoke the checked-in setup/runtime commands instead.
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.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| if (-not $up) { Write-Host " TrueForge: FAILED (check WSL ~/tf.log)" -ForegroundColor Red } | ||
| } | ||
| $out = wsl -e bash -lc "curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:3000 --max-time 4" | ||
| if ($out -eq "200") { Write-Host " TrueForge: UP" -ForegroundColor Green } |
There was a problem hiding this comment.
Suggestion: A failed TrueForge startup only prints an error and does not stop the workflow. The script proceeds through registration and dashboard startup and ultimately prints READY, so callers cannot rely on successful completion to mean the required agent runtime is available; return a failure status when the startup health check never succeeds. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Automated callers cannot trust successful completion.
- ⚠️ Dashboard starts without the required agent runtime.
- ⚠️ Users receive a false readiness indication.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/start-all.ps1
**Line:** 57:60
**Comment:**
*Incorrect Condition Logic: A failed TrueForge startup only prints an error and does not stop the workflow. The script proceeds through registration and dashboard startup and ultimately prints `READY`, so callers cannot rely on successful completion to mean the required agent runtime is available; return a failure status when the startup health check never succeeds.
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.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| $needRestart = $false | ||
| if (Test-Path $envFile) { | ||
| $envTxt = Get-Content $envFile -Raw | ||
| if ($envTxt -notmatch [regex]::Escape("TRUEFORGE_URL=http://${wslIp}:3000")) { |
There was a problem hiding this comment.
Suggestion: The refresh condition checks only TRUEFORGE_URL, but the update block also owns NEXT_PUBLIC_TRUEFORGE_URL. If the server-side URL is current while the browser-side URL is stale or missing, the condition is false and the browser continues using the wrong endpoint after a WSL IP change. Validate and update both keys independently. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Embedded TrueForge chat can target stale WSL IPs.
- ⚠️ Browser configuration diverges from server configuration.
- ⚠️ Reboot recovery can require manual environment edits.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/start-all.ps1
**Line:** 104:104
**Comment:**
*Incorrect Condition Logic: The refresh condition checks only `TRUEFORGE_URL`, but the update block also owns `NEXT_PUBLIC_TRUEFORGE_URL`. If the server-side URL is current while the browser-side URL is stale or missing, the condition is false and the browser continues using the wrong endpoint after a WSL IP change. Validate and update both keys independently.
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.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| print("[2/2] Triggering agent investigation via dashboard webhook...") | ||
| try: | ||
| result = _post(f"{DASHBOARD_URL}/api/webhook", { | ||
| "service": service, | ||
| "alert_type": chaos_type, | ||
| "message": message, | ||
| }) | ||
| print(json.dumps(result, indent=2)) | ||
| except Exception as exc: | ||
| print(f"Warning: could not reach dashboard webhook (is the dashboard running on :3001?): {exc}") |
There was a problem hiding this comment.
Suggestion: The script mutates the demo state before invoking the dashboard webhook, then suppresses webhook failures as a warning. If the dashboard is unavailable or rejects the request, chaos remains injected without an agent investigation trigger, leaving the operation partially completed; either roll back the injection or return a failure status that automation can detect. [incomplete implementation]
Severity Level: Major ⚠️
- ❌ Chaos remains active without agent investigation.
- ⚠️ Automation receives a successful exit status.
- ⚠️ Incident demonstrations become partially completed.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/trigger_incident.py
**Line:** 53:62
**Comment:**
*Incomplete Implementation: The script mutates the demo state before invoking the dashboard webhook, then suppresses webhook failures as a warning. If the dashboard is unavailable or rejects the request, chaos remains injected without an agent investigation trigger, leaving the operation partially completed; either roll back the injection or return a failure status that automation can detect.
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.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
CodeAnt Nitpicks1 code suggestion1. Unvalidated CLI values are sent to the chaos API despite documented allowlists.Api mismatch · |
- npm resolved from PATH instead of hard-coded Program Files path - stop-all only kills processes verified to be MissionControl (command-line match) - compose detection + invocation fixed for legacy docker-compose (v2 check, slice-safe) - READY block computes URL from live IP and warns to refresh stale browser tabs
- Personal WSL paths made configurable via env vars (WSL_USER, TF_RUN_SCRIPT, etc.) - MCP server started via docker-compose instead of direct python invocation - Dashboard built with 'npm run build' in setup.sh - Compose build context populated from MCP branch - Legacy compose detection fixed in setup.sh (v2 check) - Personal WSL paths replaced with configurable env vars
- Dashboard package: committed all dashboard files (was missing from branch) - Personal WSL paths: removed hardcoded defaults, now require explicit env vars - Browser URL stale: .env.local rewrite now checks/updates each var independently - Legacy Compose invocation: fixed array slice bug in setup.ps1 - Compose build context: demo-infra files committed - Launcher starts missing server: uses docker-compose for MCP server - npm path hard-coded: resolved via PATH lookup - Cleanup kills unrelated: resolved with command-line verification
… + CLI validation
codeant-ai
Bot
removed
the
size:L
Fixes pushed (review this commit for a clean re-review)
Design note (unchanged, intentional): the REST sidecar can still trigger remediation without MCP approval — that is the demo's human kill-switch path, documented in the PR body. Qodo's two remaining "Pending" items on PR #4 are the same intentional design + stale review artifacts; code there is fixed and covered by 14/14 regression tests. |
codeant-ai
Bot
added
the
size:XXL
…ersonal home paths)
codeant-ai
Bot
added
size:XXL
Finding "Startup uses personal WSL paths" — now closed (commit
|
Finding "Dashboard package is absent" — closedThis was from the original first-pass review (commit
So |
… for dashboard/demo-infra sources in setup scripts
Requesting Qodo dismissal (with reason on record) for findings #2 and #4These two findings were generated against the original commit Finding #2 — "Dashboard package is absent": claimed "that tree has no package.json or application code". Current state:
Finding #4 — "Compose build context is empty": claimed the infra directory "contains only .gitkeep". Current state:
Please dismiss with the reasoning above, or reply |
Dismissed finding 2 and finding 4 as |
…-16 sources to UTF-8
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
Bot
added
size:XXL
codeant-ai
Bot
added
size:XXL
1 participant
User description
What
Operational scripts and Docker Compose to run the full MissionControl demo stack with one command.
Components
Design notes
Next chunks
CodeAnt-AI Description
Add a local MissionControl demo that visualizes service health, injects simulated failures, and guides operators through agent-assisted recovery
What Changed
Impact
✅ Faster local incident-response demos✅ Safer rollback and restart approvals✅ Clearer service failures and recovery progress✅ Reliable recovery after cascading failures💡 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.