ops(live-worker): Railway-Worker-Config + Etappe-3-Doku-Korrekturen - #50
Conversation
Der Live-Stream-Worker läuft jetzt als eigener Railway-Service (Etappe 3 scharf geschaltet). Dieser Nachzug fixiert die dafür nötige Config-as-code und korrigiert zwei Doku-Fallen, die beim Scharfschalten auffielen: - NEU railway.worker.toml: Deploy-Config des Worker-Service (startCommand live_worker, KEIN Healthcheck, restart ON_FAILURE). Der Worker-Service zeigt via "Config-as-code file"-Setting (GraphQL railwayConfigFile) auf diese Datei — das Root-railway.toml ist Backend-only (uvicorn + /health) und würde den Worker sonst als zweiten Web-Server starten. - DEPLOY.md §8.1: --anchor-now ist ein ADDITIVES Backfill, kein In-Place- Verschieben. Auf einer bereits geseedeten DB entstehen Doppeldaten (kein Truncate/Upsert im readings-Schreibpfad). Nur auf frischer DB oder nach explizitem TRUNCATE der Daten-Tabellen nutzen — Truncate-Set + Hypertable- Backup-Hinweis ergänzt. Nicht-destruktiver Alternativweg --max-catchup-ticks dokumentiert. - DEPLOY.md §8.2: railway ssh (im Container) statt railway run (lokal) — railway.internal ist lokal nicht erreichbar. - DEPLOY.md §8.3: config-as-code-file-Mechanismus + Cross-Service-Referenz für FOREMAN_PSEUDO_KEY_v1 (kein Secret-Kopieren) dokumentiert. Reiner Ops-/Doku-Nachzug, kein App-Code-Change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
📝 WalkthroughWalkthroughDie Stage-3-Anleitung wurde um die Entscheidung zwischen ChangesLive-Daten-Stream-Worker
Sequence Diagram(s)Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@DEPLOY.md`:
- Around line 309-311: The documented Start-Command and the actual worker config
are out of sync. Update the DEPLOY.md guidance around the worker setup to match
the exact command used by railway.worker.toml via the live_worker configuration,
and make sure the runbook references the same executable invocation as the
service settings so the doc and deployed behavior stay aligned.
In `@railway.worker.toml`:
- Around line 27-28: The deployment docs currently imply unlimited automatic
restarts, but the Railway worker config uses restartPolicyType with
restartPolicyMaxRetries set to 10, so the worker will stop auto-restarting after
10 failed exits. Update the documentation or any related explanation to describe
this bounded retry behavior accurately, using the restartPolicyType and
restartPolicyMaxRetries settings as the reference points.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: a46c1cb5-e3fb-416d-874e-a63641a35c77
📒 Files selected for processing (2)
DEPLOY.mdrailway.worker.toml
| > uvicorn** starten. Lösung: Der Worker-Service zeigt via **„Config-as-code file"** | ||
| > (Service-Settings; GraphQL-Feld `railwayConfigFile`) auf **`/railway.worker.toml`** | ||
| > (Start-Command `live_worker`, kein Healthcheck, Restart `ON_FAILURE`). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Start-Command in Doku und Config angleichen.
Line 311 nennt live_worker, aber die produktive Config startet aktuell mit python -m foreman.adapters.simulation.live_worker --interval-seconds 60 (siehe railway.worker.toml, Line 24). Bitte auf einen exakten Command vereinheitlichen, damit Runbook und Service-Verhalten nicht auseinanderlaufen.
Vorschlag (Doku präzisieren)
-(Start-Command `live_worker`, kein Healthcheck, Restart `ON_FAILURE`).
+(Start-Command `python -m foreman.adapters.simulation.live_worker --interval-seconds 60`,
+kein Healthcheck, Restart `ON_FAILURE`).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| > uvicorn** starten. Lösung: Der Worker-Service zeigt via **„Config-as-code file"** | |
| > (Service-Settings; GraphQL-Feld `railwayConfigFile`) auf **`/railway.worker.toml`** | |
| > (Start-Command `live_worker`, kein Healthcheck, Restart `ON_FAILURE`). | |
| > uvicorn** starten. Lösung: Der Worker-Service zeigt via **„Config-as-code file"** | |
| > (Service-Settings; GraphQL-Feld `railwayConfigFile`) auf **`/railway.worker.toml`** | |
| > (Start-Command `python -m foreman.adapters.simulation.live_worker --interval-seconds 60`, | |
| > kein Healthcheck, Restart `ON_FAILURE`). |
🧰 Tools
🪛 LanguageTool
[typographical] ~309-~309: Zeichen ohne sein Gegenstück: ‚“‘ scheint zu fehlen
Context: ... Lösung: Der Worker-Service zeigt via „Config-as-code file" > (Service-Settin...
(DE_UNPAIRED_QUOTES)
[style] ~310-~310: Möchten Sie die modernere Schreibweise „GrafQL-Feld“ verwenden?
Context: ...ig-as-code file"** > (Service-Settings; GraphQL-Feld railwayConfigFile) auf **`/railway.wo...
(F_ANSTATT_PH)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@DEPLOY.md` around lines 309 - 311, The documented Start-Command and the
actual worker config are out of sync. Update the DEPLOY.md guidance around the
worker setup to match the exact command used by railway.worker.toml via the
live_worker configuration, and make sure the runbook references the same
executable invocation as the service settings so the doc and deployed behavior
stay aligned.
| restartPolicyType = "ON_FAILURE" | ||
| restartPolicyMaxRetries = 10 |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor
🧩 Analysis chain
🌐 Web query:
Railway config-as-code: What exactly does deploy.restartPolicyMaxRetries do with restartPolicyType=ON_FAILURE, and does the service stop permanently after reaching the retry limit?
💡 Result:
When using Railway's Config-as-Code to set restartPolicyType to ON_FAILURE, the restartPolicyMaxRetries setting defines the maximum number of times Railway will attempt to automatically restart your service if it exits with a non-zero exit code [1][2][3]. Yes, the service stops permanently after reaching this retry limit [2][3]. Specifically, if the service crashes and exceeds the configured restartPolicyMaxRetries limit, the deployment status is changed to Crashed, and the service will no longer attempt to restart automatically [2][3]. Once in this Crashed state, you must manually intervene—such as by clicking the "Restart" button in the Railway dashboard or triggering a redeploy—to bring the service back online [2][3]. In summary, the retry limit serves as a safeguard to prevent infinite restart loops for services that are fundamentally failing. If a process repeatedly exits with errors, Railway halts the cycle to prevent further resource consumption and to notify you of the failure via webhooks and email [2][3].
Citations:
- 1: https://docs.railway.com/deployments/restart-policy
- 2: https://github.com/railwayapp/docs/blob/76db91a4/content/docs/deployments/deployment-actions.md
- 3: https://docs.railway.com/deployments/deployment-actions
restartPolicyMaxRetries begrenzt Auto-Restarts auf 10 Versuche
restartPolicyType = "ON_FAILURE" startet nur bei Fehl-Exits neu; nach 10 Fehlstarts wechselt Railway auf Crashed und startet nicht mehr automatisch. Wenn der Worker dauerhaft laufen soll, sollte die Deploy-Doku das nicht als unbegrenztes Restart-Verhalten beschreiben.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@railway.worker.toml` around lines 27 - 28, The deployment docs currently
imply unlimited automatic restarts, but the Railway worker config uses
restartPolicyType with restartPolicyMaxRetries set to 10, so the worker will
stop auto-restarting after 10 failed exits. Update the documentation or any
related explanation to describe this bounded retry behavior accurately, using
the restartPolicyType and restartPolicyMaxRetries settings as the reference
points.
1 participant
Kontext
Der Live-Daten-Stream-Worker (PR #47) ist auf Railway scharf geschaltet (Etappe 3): eigener Service
live-worker, Singleton (replicas=1), RestartON_FAILURE, kein Healthcheck. Live verifiziert —max(time)derreadingswandert mit der Wall-Clock (Lücke < 1 Tick),/overview → stream.active = true, Neustart resumed ohne Doppel (dup = 0).Dieser PR ist der reine Ops-/Doku-Nachzug dazu — kein App-Code-Change.
Was drin ist
railway.worker.toml(neu)Config-as-code des Worker-Service:
startCommand = live_worker --interval-seconds 60, kein Healthcheck, RestartON_FAILURE. Der Worker-Service zeigt via Service-Setting „Config-as-code file" (GraphQLrailwayConfigFile) auf diese Datei — das Root-railway.tomlist Backend-only (alembic+uvicorn+ Healthcheck/health) und config-as-code überschreibt Dashboard-Settings, würde den Worker also sonst als zweiten Web-Server starten.DEPLOY.md§8 — drei beim Scharfschalten verifizierte Korrekturen--anchor-nowist additiv, kein In-Place-Verschieben. Auf einer bereits geseedeten DB erzeugt es Doppeldaten (kein Truncate/Upsert imreadings-Pfad). Jetzt klar dokumentiert: nur auf frischer DB oder nach explizitemTRUNCATEder Daten-Ebene (Truncate-Set + Hypertable-Backup-Hinweis, dapg_dump -t readingsdie Chunks nicht erfasst). Nicht-destruktiver Default-Weg--max-catchup-ticksergänzt.railway sshstattrailway run.railway runläuft lokal;railway.internalist von dort nicht erreichbar — die Live-DB nur über Private Networking im Container.${{backend.FOREMAN_PSEUDO_KEY_v1}}für den Pseudo-Key (kein Secret-Kopieren, konsistente Pseudonyme);JWT_SECRETbraucht der Worker nicht.Hinweis
Der laufende
live-worker-Service wurde viarailway up-Upload scharf geschaltet (dierailway.worker.tomllag im Upload-Snapshot). Nach Merge kann der Service optional auf GitHub-Source umgestellt werden — dann liegt die Config inmain.🤖 Generated with Claude Code
Summary by CodeRabbit