ux(prs/finish): mergeability is invisible on the typed surface — get hides mergeable/merge_base, finish's 405 advice says retry when the PR is flagged unmergeable #22

New issue

Closed

opened 2026-07-11 21:45:54 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-11 21:45:54 +00:00

(Migrated from codeberg.org)

Gaps (hit live, 2026-07-10, an earlier PR)

madt_prs action=get formatted output omits merge-relevant state. mergeable, merged, merge_base, and changed_files/additions/deletions are exactly what an agent needs when a merge fails, but the formatted view doesn't show them — the only routes are raw_json=true (a multi-KB dump with two full repo objects embedded) or falling back to madt_api_call with jq. Both are the escape hatch the typed tool should make unnecessary.
madt_finish's merge-failure advice is blind to WHY. On Gitea's 405 "Please try again later" it retries 3× then says "re-run finish or merge with 'madtea pr merge'" — but in today's case the PR was sitting at mergeable: false (stale async recompute after a fresh push). Re-running finish just re-hits the same 405. The failure handler should fetch the PR's mergeable state and say which situation you're in: still-computing (retry is right), genuinely conflicted (retry is wrong — rebase/resolve first), or server-side flake.

Ask

madt_prs action=get: add a merge-state line to the formatted output (mergeable / merged / merge_base / changed_files +adds −dels).
madt_finish merge step: on merge failure, include the PR's current mergeable state in the error and tailor the advice to it.
Consider raw_json PR payloads dropping the two embedded full repo objects (base.repo/head.repo) — they dominate the payload and an agent almost never wants them.

## Gaps (hit live, 2026-07-10, an earlier PR) 1. **`madt_prs action=get` formatted output omits merge-relevant state.** `mergeable`, `merged`, `merge_base`, and `changed_files`/`additions`/`deletions` are exactly what an agent needs when a merge fails, but the formatted view doesn't show them — the only routes are `raw_json=true` (a multi-KB dump with two full repo objects embedded) or falling back to `madt_api_call` with `jq`. Both are the escape hatch the typed tool should make unnecessary. 2. **`madt_finish`'s merge-failure advice is blind to WHY.** On Gitea's 405 "Please try again later" it retries 3× then says "re-run finish or merge with 'madtea pr merge'" — but in today's case the PR was sitting at `mergeable: false` (stale async recompute after a fresh push). Re-running finish just re-hits the same 405. The failure handler should fetch the PR's mergeable state and say which situation you're in: still-computing (retry is right), genuinely conflicted (retry is wrong — rebase/resolve first), or server-side flake. ## Ask - `madt_prs action=get`: add a merge-state line to the formatted output (mergeable / merged / merge_base / changed_files +adds −dels). - `madt_finish` merge step: on merge failure, include the PR's current mergeable state in the error and tailor the advice to it. - Consider `raw_json` PR payloads dropping the two embedded full repo objects (base.repo/head.repo) — they dominate the payload and an agent almost never wants them.

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#22

No description provided.

Rows
Columns