Reproduce unspecified merge-adapter concerns from PR #23 review #33

Activity

1. mchwang commented on Oct 5, 2026

   

   mchwang

   on Oct 5, 2026

   ContributorAuthor

   More actions

   Reproduced the two concrete failure cases implied by the final PR #23 review summary at exact reviewed head e2c3aea6d71e68abad3e547e1bcc808d2fa3059c:

   1. Lost-response duplication: after one successful merge submission whose response is lost, a fresh coordinator accepts the same review token and invokes the merge gateway a second time. The focused failing-before regression expected one invocation and observed two.
   2. Ambiguous post-submit ownership: when the merge request may have been sent but the transport reports connection reset, the coordinator releases its in-memory guard and a retry invokes the merge gateway again. The focused failing-before regression expected retained in-flight/reconciliation state and observed a second submission.

   These were genuine defects, but they have already been addressed by later merged work:

   • PR Complete merge-queue lifecycle and retry guards #46 added durable submitting ownership, ambiguous-outcome retention, and external-state reconciliation.
   • PR F1a: persist the runner lifecycle in the Store #53 added required action IDs, durable outcome replay, and lost-response idempotency.

   Validated current origin/main at 10c7c5e2f0f2bbb60848f706366f27ad476be81b with the focused existing regressions:

   • replays a resent merge click after a lost response instead of submitting again
   • keeps the key-bearing attempt in flight after an unknown outcome, then replays the reconciled URL
   • replays a direct click that is still submitting as an unknown outcome, not as a success
   • keeps an unknown enqueue failure submitting until external reconciliation

   Result: 4 passed, 132 skipped in test/merge.test.ts.

   No new patch is needed. Closing as completed by PRs #46 and #53.
2. mchwang

   closed this as completedon Oct 5, 2026