fix(scheduler.registry): ensure started_at always populated on cron fires#60
Merged
Conversation
PR #55 fixed insertRunV2's JS-side default, but the registry→dispatcher cron-fire path was STILL surfacing "null value in column started_at" in prod logs. Hardens two remaining gaps: 1. hub/src/db/dal.ts insertDeploymentRun — was inserting NULL into started_at when status='pending' (coolify-webhook deployment-marker rows). Now always now(). started_at is "row created"; that's correct for pending too. 2. hub/src/db/scheduled-tasks-dal.ts insertRunV2 — SQL now wraps the bound started_at in COALESCE(_, now()), so even an accidentally-null bind from a future caller resolves server-side. JS-side default (input.started_at ?? new Date()) stays as the primary guard. Schema.sql already has ALTER COLUMN started_at SET DEFAULT now() from PR #55 — that runs on every boot via migrate.ts (verified). Regression tests cover explicit null + the deployment-run path.
4 tasks
finedesignz
added a commit
that referenced
this pull request
May 26, 2026
The Titanium JWKS warm at boot called process.exit(1) on any failure,
which has been taking down every Coolify deploy of remo-code-hub since
the upstream Keygen JWKS endpoint at
`/v1/accounts/{ACCOUNT_ID}/.well-known/jwks.json` returns 404.
Architecturally, a stalled Titanium JWKS endpoint should never block the
hub from binding its port — the hub serves health checks, public
webhooks (Coolify, Sentry intake), the web SPA, the scheduler, and the
agent WebSocket, none of which require Titanium JWT verification. Only
license-gated routes do, and those fail closed at request time via
`verifyLicenseJwt` which already lazy-warms on first use through
jose's `createRemoteJWKSet` resolver.
Change: log the warm failure loudly and continue binding the port.
Misconfiguration remains visible in deploy logs; production stays up.
Unblocks PR #60 (started_at scheduler fix) from going live before the
midnight cron fires.
4 tasks
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
1 participant
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.
Summary
PR #55 fixed
insertRunV2's JS default, but[scheduler.registry] fire failed: null value in column started_atwas STILL appearing in prod logs.Two remaining gaps closed:
hub/src/db/dal.tsinsertDeploymentRun— was passing literal JSnullforstarted_atwhenstatus === 'pending'. Coolify webhooks hitting this path produced NOT NULL violations. Now alwaysnow().hub/src/db/scheduled-tasks-dal.tsinsertRunV2— SQL now wraps the boundstarted_atinCOALESCE(_, now()). Belt-and-suspenders: even if a future caller passesnullexplicitly, the server resolves it.Schema migration
ALTER COLUMN started_at SET DEFAULT now()from PR #55 is already inschema.sqland runs on boot viamigrate.ts.Test plan
bun test hub/test/insert-run-started-at.test.ts— 5 pass / 0 failstarted_at: nullstill produces a Date + SQL contains COALESCEinsertDeploymentRuntest verifies no NULL slot