fix(hub): cron ticker delivers as an authorized mailbox sender (CL-8533) - #919
Merged
Merged
Conversation
A due cron schedule was handed to the mailbox persist path with a synthesized `cron@<domain>` sender. That path authorizes a sender against a live routable endpoint — only an open workflow run address resolves — so the mailbox write was refused and the hub's own persist threw for the same reason. Nothing was delivered, and the run was never triggered: persisting mail records does not fire a run. A schedule firing with nobody signed in is a trigger, not a person's mail. It now takes the route an inbound webhook already takes: materialize the run's mail-triggered grants, hand them to the sidecar, and route a signed frame in which the run is the authenticated sender of its own trigger mail. No authorization check is skipped; the frame never enters the mailbox sender path. The ticker no longer invents a sender address — it names the tenant and leaves the identity to the host — and one schedule's failed delivery is now reported and isolated instead of aborting the whole tick.
The hub is upstream server.ts plus one Corbits block, so the run-trigger frame assembly does not belong in a hub file. @corbits/webhooks now exports the deliverer it already had internally, with a caller-supplied sender local part; @corbits/cron fans a due schedule's recipients out over it.
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.
A cron schedule fires with nobody signed in, so it could not ride the mailbox persist path: that path authorizes its sender against a live routable endpoint, and
cron@<domain>is not one — every tick failed.A due schedule is a system trigger, exactly like an inbound webhook, so it now takes the same route an inbound webhook takes: materialize the run's mail-triggered grants, hand them to the sidecar, then route a signed trigger frame in which the run is the authenticated sender of its own trigger mail. No authorization check is skipped — the frame never enters the mailbox sender path at all.
That frame assembly already existed inside
@corbits/webhooks, so it lives there rather than in a new hub file (the hub is upstreamserver.tsplus one Corbits block):@corbits/webhooksnow exportscreateRunTriggerDelivererwith a caller-supplied sender local part and subject (feat: export createRunTriggerDeliverer for other system triggers webhooks#4, no behavior change on the webhook path); repinned here.packages/crongainscreateRunTriggerCronDeliver, which fans a due schedule's recipients out over that deliverer.DeliverCronMailnames the tenant instead of inventing afrom: only the host knows which addresses its transport authorizes.onDeliveryErrorand every due row still advances, so one undeliverable schedule cannot re-fire every minute forever.systemTriggerMailRouter.Files:
apps/hub/package.json,apps/hub/src/server.ts,packages/cron/src/{index,ticker,deliver,deliver.test}.ts.