(motir-core) TWO event-triggered jobs landed after MOTIR-3463's wave and are still unrouted — `plan-drift/transitioned` and `public-follow/digest` are on Inngest and no card owns them
Opened by Zhu Yue ·
Found while running MOTIR-3682. Same defect class as that card, different population: MOTIR-3682 is about the SCHEDULED lane and is explicitly forbidden from widening the routed set beyond its one id, so these two are not its to fix.
The measurement
Taken on origin/main at 555932db92fe0aca9d7771766e501aa0a7102ff1 (2026-08-27), and against the live MOTIR_POSTGRES_JOB_IDS read from inside motir-core machine 8576143c4ee538 at 2026-08-27T10:31Z:
git grep -hoE "id: '[^']+'" -- lib/jobs/definitions | sed "s/id: '//;s/'//" | sort -u → 40 job ids
live MOTIR_POSTGRES_JOB_IDS → 34 ids
The six defined-but-unrouted ids, and who owns each:
| id | kind | owner |
|---|---|---|
system.ci-runner-boot | container supervisor | MOTIR-3489 |
system.code-graph-index | container supervisor | MOTIR-3489 |
system.code-graph-refresh | container supervisor | MOTIR-3489 |
system.public-follow-digest-tick | scheduled | MOTIR-3682 |
plan-drift/transitioned | event-triggered | nobody — this card |
public-follow/digest | event-triggered | nobody — this card |
Why they are unowned
MOTIR-3463 — "Cut the 20 event-triggered jobs over IN PRODUCTION" — routed 20 and is done. There are now 22. Both extras arrived after that card was authored:
lib/jobs/definitions/planDrift.ts—plan-drift/transitioned, merged 2026-08-26 20:39Z (#2309, MOTIR-3560)lib/jobs/definitions/publicFollowDigestDeliver.ts—public-follow/digest, merged 2026-08-27 07:07Z (#2344, MOTIR-1103)
Both run on Inngest today, which is lib/jobs/engine/cutover.ts's documented default and is not itself broken. The consequence is deferred: MOTIR-3418 deletes the Inngest SDK and serve route on the premise that nothing remains there, and at that moment these two events lose their subscriber on both lanes — silently, with no error.
public-follow/digest is the more consequential of the two: it is the per-follower fan-out that system.public-follow-digest-tick enqueues, so once MOTIR-3682 routes the tick to the engine, the tick runs on the engine and hands its work to a job that is still on Inngest. That composition is legal (the switch is per-job and sendEvent routes each independently) but it is not a state to leave standing.
Fix direction
Add both ids to MOTIR_POSTGRES_JOB_IDS, then read one succeeded job_run row back per id from the ledger — plan-drift/transitioned by transitioning a work item on a project with an approved plan, public-follow/digest by letting the routed weekly tick fan one out (or by emitting one directly). Then extend the census in lib/jobs/engine/cutover.ts that MOTIR-3682 introduces, moving both ids from the Inngest side to the engine side; the guard test asserts the census is total over the registry, so the move is what makes the build agree with production.
Acceptance criteria
plan-drift/transitionedandpublic-follow/digestare both in the liveMOTIR_POSTGRES_JOB_IDS, verified from inside a machine, and the full value is recorded verbatim.- One engine-lane
succeededjob_runrow is quoted per id, with itsevent_idandstarted_at. - The three container-supervisor ids are still absent (this card must not take MOTIR-3489's scope).
lib/jobs/engine/cutover.ts's census lists both ids on the engine side, andtests/jobs/cutover-census.test.tsis green against it.- After this card and MOTIR-3682 and MOTIR-3489, the census's Inngest side is EMPTY — which is the condition MOTIR-3418 is premised on.
Context refs
lib/jobs/definitions/planDrift.ts·lib/jobs/definitions/publicFollowDigestDeliver.ts— the two jobslib/jobs/engine/cutover.ts— the switch, its Inngest default, and (after MOTIR-3682) the censustests/jobs/cutover-census.test.ts— the totality guard MOTIR-3682 adds- MOTIR-3463 — routed 20 of 22; its record explains why
Discussion
No comments yet.
Adding to this discussion signs you in on app.motir.co and brings you back to this request.