Skip to content

Submit consents for the headless worker - #4

Merged
mcheemaa merged 2 commits into
mainfrom
fix/dd-submit-confirmation
Aug 12, 2026
Merged

mcheemaa merged 2 commits into
mainfrom
fix/dd-submit-confirmation

Conversation

@mcheemaa

Copy link
Copy Markdown
Owner

The first production ceremony failed twice with dd-cli timed out after 30s on order submit, while every call before it succeeded. Root cause: order submit has an interactive confirmation prompt (-y, --yes to skip, per its own help), we never passed the flag, and a cloud worker has no TTY, so the CLI waited for a keypress until our timeout killed it. It was the only verb with a confirmation gate and the only verb never exercised before the ceremony.

  • orderSubmit now passes --yes and gets a 120s timeout of its own; payment authorization is the CLI's slowest call and the 30s read-call ceiling starved it.
  • When an uncertain submit reconciles against order history and finds nothing landed, the cart reopens instead of staying sealed with no recovery route (the ceremony left a cart stranded at placing).
  • Regression test pins --yes and the timeout onto the submit args.

Worth noting: both failures failed safe. Honest unknown outcomes, an immediate order-history reconcile by the agent, zero orders created, zero dollars moved. The paper trail in dd_approvals and dd_orders reads exactly as designed.

Gates green: lint, typecheck, 298 tests, build.

The first ceremony failed twice at the exact same wall: order submit
timed out at 30 seconds while everything before it succeeded. The CLI's
submit has an interactive confirmation, the one flag list we never read
in full because submit was the one call we never rehearsed, and a
headless worker has no keypress to give. --yes now rides every submit;
the human yes already happened, in the owner's inbox.

Two companions from the same post-mortem: submit gets a 120 second
timeout of its own, since payment authorization is the slowest call in
the CLI and the read-call ceiling starved it; and when an uncertain
submit reconciles against order history and finds nothing landed, the
cart reopens instead of staying sealed forever, which is the stranding
the ceremony proved. A regression test pins --yes and the patient
timeout to the submit args.

For the record, the machine failed safe both times: honest unknown
outcomes, an immediate history reconcile by the agent, zero dollars
moved.
@vercel

vercel Bot commented Aug 12, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
rendi Ready Ready Preview Aug 12, 2026 7:38pm

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9fc1e3490f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread trigger/tools/doordash-submit.ts Outdated
// History says nothing landed, so the cart is intact by
// definition; leaving it sealed would strand it, which is
// what the first ceremony proved.
await setCartStatus(approval.cartUuid, "open");

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Keep uncertain carts sealed until reconciliation

When submission times out or loses its response, an immediate history miss does not prove that no order landed, especially because reconcileFromHistory also returns null when the history request itself fails. Reopening the cart here removes the mutation guard while the order may already have been accepted and charged, allowing edits or a fresh approval that can produce a duplicate order. Keep the cart in an uncertain sealed state until a later successful reconciliation establishes the outcome.

Useful? React with 👍 / 👎.

Codex round one, one finding, accepted in full. Reopening the cart on
an immediate history miss conflated two different truths: history
saying nothing landed, and history failing to answer at all, while
even an honest empty read seconds after a timeout cannot rule out an
order still materializing. So the cart now stays sealed on unknown,
and calling doordash-submit again with the same approval id IS the
settle loop: consumption answers alreadyConsumed, the tool asks
history again, adopts the order if one landed, and releases the cart
only when a successful later look confirms nothing ever did. The
reconciler moved into the wrapper as a tri-state (found, none,
unavailable) with tests for each face, and both submit paths settle
through one shared poll.
@mcheemaa

Copy link
Copy Markdown
Owner Author

Accepted in full, landed in 01965cd. The immediate-miss reopen conflated an empty history with an unreachable one, and even an honest empty read cannot rule out an order still materializing after a timed-out submit. New design: unknown keeps the cart sealed, and re-calling doordash-submit with the same approval id is the settle loop (consume answers alreadyConsumed, the tool re-reconciles, adopts a landed order, and reopens the cart only after a successful later look finds nothing). The reconciler is now a tri-state in the wrapper with tests for each face.

@mcheemaa
mcheemaa merged commit 08c39b1 into main Aug 12, 2026
7 checks passed

This branch was successfully deployed

1 active deployment
Preview — 01965cd3 Deployed Aug 12, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant