Repository navigation
fix(queue): skip scheduling HUBSPOT_SYNC when HUBSPOT_API_KEY is unset - #291
Merged
Merged
Conversation
Without the key every HUBSPOT_SYNC run fails at HubSpot client construction and dead-letters (prod worker, last 24h). The scheduler now leaves the job out of its default schedule when the key is unset, empty or whitespace, and logs one startup line saying so. With a key set the schedule is unchanged, so the sync comes back once a key is added.
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.
What
The worker scheduled
HUBSPOT_SYNCevery day even though prod has noHUBSPOT_API_KEY, so every run failed at HubSpot client construction and dead-lettered (prod worker logs, last 24h). Per Nathan, the sync is off for now.resolveScheduledJobs()inpackages/outpost/queue/src/scheduler.tsdropsHUBSPOT_SYNCfrom the default schedule whenHUBSPOT_API_KEYis unset, empty or whitespace, and logs one startup line:With a key set the schedule is unchanged, so the sync comes back on the next worker start after a key is added.
Why the scheduler, not the job handler
A guard in the handler would still create a job row every day and mark it done or failed. In the scheduler, no row is created, and the
Starting with N scheduled jobscount is correct.new Scheduler(definitions)with explicit definitions is not affected. The HubSpot client, the handler, the web sync route and the other jobs are not changed.Local red-green proof (real
Schedulerfromqueue/dist, local Postgrespgvector:pg16, migrations applied)The harness builds the package, clears
job, runsnew Scheduler().start()for 3s, stops it, and lists the job rows it created. In the RED run it also passes the HUBSPOT_SYNC row to the realhandleHubSpotSync. With the dummy key, it stops at scheduling and makes no HubSpot call. The key value is redacted.RED (before the fix, key unset)
GREEN (after the fix)
Unit tests (
queue/src/__tests__/scheduler.test.ts)resolveScheduledJobs: unset, empty or whitespace key drops HUBSPOT_SYNC and logs the skip line once. A set key keeps every default job and logs nothing.Schedulerwith default definitions (prisma andcreateJobmocked): no HUBSPOT_SYNC job without a key. A HUBSPOT_SYNC job with a key.Against the old code, 5 of the new tests fail: the 4
resolveScheduledJobscases, and "never creates a HUBSPOT_SYNC job when HUBSPOT_API_KEY is unset". The "key set" Scheduler test passes on both, because that behavior does not change. After the fix, 8/8 pass.Local checks
packages/outpost: 0 errors. The changed files have no warnings.packages/outpostandapps/workerpasspackages/outpost/queue560/560,apps/worker84/84. Fullpackages/outpost: 4966/4967. The 1 failure isai/src/classifier-backtracking.test.ts("starts the probe child cleanly"), which fails the same way onmainwithout this change. Local Node v26 prints a DEP0205 warning to the child stderr.