fix(finish/merge): back off and wait on Gitea 405 "Please try again later" instead of 3 rapid attempts → hard fail #13

New issue

Closed

opened 2026-07-11 21:19:55 +00:00 by hexajon · 1 comment

hexajon commented

2026-07-11 21:19:55 +00:00

(Migrated from codeberg.org)

Problem

When Gitea answers a merge with 405 {"message":"Please try again later"} — its transient "PR not ready" response, e.g. while the mergeability check is still running right after the PR was just created/pushed — madtea burns its 3 retry attempts back-to-back and hard-fails. We hit this a lot.

Fresh reproduction (2026-07-10, another repo's PR):

madt_finish (branch= form): push + PR create succeed, merge step fails — merge failed: Gitea was temporarily unavailable ("try again later") after 3 attempts ... API error 405.
Immediate re-run of finish: same 405 after 3 more attempts. Six rapid attempts total, zero meaningful wall-clock between them.

The error message already correctly identifies the situation ("temporarily unavailable", "retry in a moment") — but the human/agent is told to wait while the client never does.

Ask

A small wait between retry attempts on this specific transient signal:

Detect the transient case: HTTP 405 with the "Please try again later" body (NOT a generic 405 Method Not Allowed — those should still fail immediately).
Retry with a short backoff (e.g. ~1s → 2s → 4s, small jitter; honor a Retry-After header if Gitea ever sends one). Total extra wall-clock budget on the order of 10–30s, not minutes.
Apply wherever the merge is issued: the merge step of finish and madt_prs action=merge / madtea pr merge (and orchestrate's batch merge, which presumably shares the path).
On budget exhaustion, keep today's error text (it's good — actionable, names the open PR).

Acceptance

A merge that 405-transients twice then succeeds completes in one finish/merge call, with the waits logged/visible.
A genuine 405 (method not allowed, different body) still fails immediately.
Hermetic tests: fake client returning 405-transient N times then success; budget-exhausted path preserves the current error message.

## Problem When Gitea answers a merge with `405 {"message":"Please try again later"}` — its transient "PR not ready" response, e.g. while the mergeability check is still running right after the PR was just created/pushed — madtea burns its 3 retry attempts back-to-back and hard-fails. We hit this a lot. Fresh reproduction (2026-07-10, another repo's PR): 1. `madt_finish` (branch= form): push + PR create succeed, merge step fails — `merge failed: Gitea was temporarily unavailable ("try again later") after 3 attempts ... API error 405`. 2. Immediate re-run of finish: same 405 after 3 more attempts. Six rapid attempts total, zero meaningful wall-clock between them. The error message already correctly identifies the situation ("temporarily unavailable", "retry in a moment") — but the *human/agent* is told to wait while the *client* never does. ## Ask A small wait between retry attempts on this specific transient signal: - Detect the transient case: HTTP 405 with the "Please try again later" body (NOT a generic 405 Method Not Allowed — those should still fail immediately). - Retry with a short backoff (e.g. ~1s → 2s → 4s, small jitter; honor a `Retry-After` header if Gitea ever sends one). Total extra wall-clock budget on the order of 10–30s, not minutes. - Apply wherever the merge is issued: the merge step of `finish` and `madt_prs action=merge` / `madtea pr merge` (and orchestrate's batch merge, which presumably shares the path). - On budget exhaustion, keep today's error text (it's good — actionable, names the open PR). ## Acceptance - A merge that 405-transients twice then succeeds completes in one `finish`/`merge` call, with the waits logged/visible. - A genuine 405 (method not allowed, different body) still fails immediately. - Hermetic tests: fake client returning 405-transient N times then success; budget-exhausted path preserves the current error message.

hexajon commented

2026-07-13 17:09:19 +00:00

(Migrated from codeberg.org)

short backoff should be longer like 5s -> 10s -> 15s

No milestone

No project

No assignees

1 participant

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

sixfold-space/madtea#13

No description provided.

Rows
Columns