stackchain/stackchain-dashboard
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases 713 Wiki Activity

Reconcile ambiguous merge outcomes after upstream timeouts #277

New Issue
Closed
opened 2026-08-08 07:29:29 +00:00 by timmy · 0 comments
timmy commented 2026-08-08 07:29:29 +00:00
Owner
Copy Link

Problem

The assigned pull-request merge endpoint wraps the mutation in a five-second timeout. If Gitea accepts the merge but its response is delayed or lost, the dashboard returns 503 and claims the pull remains in My Work. Retrying can then target an already-merged pull.

User impact

Operators completing the mobile review-to-merge flow cannot trust whether a timed-out merge shipped. The dashboard should confirm authoritative state without issuing a duplicate merge.

Acceptance criteria

  • A merge accepted before an upstream timeout is reconciled to a confirmed successful response.
  • Reconciliation verifies the exact expected head SHA and issues exactly one merge POST.
  • An unresolved result is described as confirmation pending; it never asserts the pull remains open without evidence.
  • Stale-head and ineligible-pull conflicts retain existing behavior.
  • The healthy merge path adds no extra upstream read.
  • Behavioral tests cover accepted-before-timeout, unresolved reconciliation, and normal success.

Non-duplication evidence

No open issue is eligible or covers merge outcome reconciliation. Historical issues #161 and #240 added mobile merge flows, while #177/#185 cover idempotency for issue capture/authored actions; none confirms merge state after a delayed or lost upstream response. Repository search found no merge timeout reconciliation implementation.

## Problem The assigned pull-request merge endpoint wraps the mutation in a five-second timeout. If Gitea accepts the merge but its response is delayed or lost, the dashboard returns 503 and claims the pull remains in My Work. Retrying can then target an already-merged pull. ## User impact Operators completing the mobile review-to-merge flow cannot trust whether a timed-out merge shipped. The dashboard should confirm authoritative state without issuing a duplicate merge. ## Acceptance criteria - A merge accepted before an upstream timeout is reconciled to a confirmed successful response. - Reconciliation verifies the exact expected head SHA and issues exactly one merge POST. - An unresolved result is described as confirmation pending; it never asserts the pull remains open without evidence. - Stale-head and ineligible-pull conflicts retain existing behavior. - The healthy merge path adds no extra upstream read. - Behavioral tests cover accepted-before-timeout, unresolved reconciliation, and normal success. ## Non-duplication evidence No open issue is eligible or covers merge outcome reconciliation. Historical issues #161 and #240 added mobile merge flows, while #177/#185 cover idempotency for issue capture/authored actions; none confirms merge state after a delayed or lost upstream response. Repository search found no merge timeout reconciliation implementation.
timmy self-assigned this 2026-08-08 07:29:29 +00:00
timmy closed this issue 2026-08-08 07:34:43 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
P0

Drop everything

  
P1

High priority

  
P2

Medium priority

  
agent:nightprowl

Assignments routed to the LongCat NightProwl evaluation worker

  
backend

Backend service

  
ci

Continuous integration / actions

  
frontend

Frontend / UI

  
meta

Meta / planning

  
pages

Gitea Pages

  
template

Repo template / standards

No Label
P0
P1
P2
agent:nightprowl
backend
ci
frontend
meta
pages
template
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
timmy
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#277
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?