Repository navigation
Submit consents for the headless worker - #4
Conversation
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.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 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".
| // 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"); |
There was a problem hiding this comment.
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.
|
Accepted in full, landed in |
The first production ceremony failed twice with
dd-cli timed out after 30sonorder submit, while every call before it succeeded. Root cause:order submithas an interactive confirmation prompt (-y, --yesto 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.orderSubmitnow passes--yesand gets a 120s timeout of its own; payment authorization is the CLI's slowest call and the 30s read-call ceiling starved it.placing).--yesand the timeout onto the submit args.Worth noting: both failures failed safe. Honest
unknownoutcomes, 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.