Repository navigation
ops(railway): mark company-monitoring-worker planned so the post-#6397 apply can run (#6402) - #6403
Merged
Merged
Conversation
…apply can run (#6402) #6397 widened the registry — `.dockerignore`, direct Dockerfile COPY inputs, `.d.ts` files, tsconfigs — but a registry change is not Railway truth. Only `audit-railway-watch-paths.mjs --apply` pushes it, and that apply was refusing: company-monitoring-worker not present in Railway production; refusing a partial config apply #6386 shipped `scripts/company-monitoring-worker.mjs` and its registry entry with nothing provisioned: no Railway service, and no COMPANY_MONITORING_WORKER_SECRET in the local env file or in any of Railway's 92 shared variables. Unmarked, that entry reads as a missing service, and buildRailwayServiceConfigPatch refuses a partial apply — so one unprovisioned entry stranded #6397's watch paths for six OTHER services, including the exact build-input closure `umami` needs to stop being BEHIND since 2026-08-09 16:23 (#6381). `lifecycle: "planned"` is the registry's own mechanism for declared-but-unprovisioned (audit-railway-watch-paths.mjs:143; four seeders already use it). Applied here as a deliberate PAUSE rather than a staging state: unlike those seeders, this module's header says "always-on Railway service" and health polls it on a 5-minute budget, so provisioning it (#6402) must take it back off the list. The allow-list in tests/railway-watch-path-audit.test.mjs is exact on purpose — `planned` removes an entry from both the live audit and `--apply`, so every addition has to be a decision someone made rather than a way to quiet a red gate. Updated with the reasoning and the condition that reverses it. Applied to production after this change, with the registry read from this tree: Applied and verified registry-managed config for 6 Railway service(s) in production. (ais-relay, digest-notifications, seed-bundle-portwatch-port-activity, seed-bundle-resilience-validation, umami, umami-retention) $ node scripts/audit-railway-watch-paths.mjs Railway operational-config audit passed: ... exit 0 The applied config equals what main declares for those six; this change only excludes the unprovisioned entry from the patch. 99 registry tests pass; 154 sibling Railway/monitor tests pass; biome clean. Claude-Session: https://claude.ai/code/session_014iaXRJN9n59i1ZDTd3JLy2
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Unblocks the post-#6397 watch-path apply, which is already applied to production — see
Verification. Refs #6402, #6381.
Why the apply was stuck
#6397 widened the registry (
.dockerignore, direct DockerfileCOPYinputs,.d.tsfiles,tsconfigs). A merged registry change is not Railway truth: only
audit-railway-watch-paths.mjs --applypushes it, and that apply was refusing outright:#6386 shipped
scripts/company-monitoring-worker.mjsand its registry entry with nothingprovisioned — no Railway service, and no
COMPANY_MONITORING_WORKER_SECRETin the local envfile or in any of Railway's 92 shared variables. Unmarked, the entry reads as a missing
service, and
buildRailwayServiceConfigPatchrefuses a partial apply. So one unprovisionedentry stranded #6397's watch paths for six other services — including the exact
build-input closure
umamineeds to stop beingBEHINDsince 2026-08-09 16:23 (#6381).The change
lifecycle: "planned"is the registry's own mechanism for declared-but-unprovisioned(
audit-railway-watch-paths.mjs:143); four seeders already use it.Applied here as a deliberate pause, not a staging state. Unlike those seeders, this
module's header says "always-on Railway service" and
api/health.jspolls it on a 5-minutebudget — the gate was correctly reporting a real provisioning gap. Provisioning it (#6402)
must take it back off the list, and the test comment says so.
The allow-list in
tests/railway-watch-path-audit.test.mjsis exact on purpose:plannedremoves an entry from both the live audit and
--apply, so every addition has to be adecision somebody made rather than a way to quiet a red gate. Updated with the reasoning and
the condition that reverses it.
Verification
Applied to production with the registry read from this tree — the applied config equals what
maindeclares for those six services; this change only excludes the unprovisioned entry fromthe patch:
main()re-reads the environment after patching and fails if drift remains, so the applyproves itself.
railway-watch-path-audit,railway-services-registry-coverage,railway-watch-path-drift-regression,dockerfile-digest-notifications-imports).npx biome checkclean.The
Audit Railway ingestion deployment controlsstep of the Seed Freshness Monitor should gogreen on the next scheduled run.
https://claude.ai/code/session_014iaXRJN9n59i1ZDTd3JLy2