Commit graph

5 commits

Author SHA1 Message Date
nesquena-hermes
94d3cd5e95 Stage 318: PR #1870 — Fix Kanban stale-client false-positive by @franksong2702 2026-05-08 15:01:49 +00:00
Frank Song
153c34cac0 fix: tighten Kanban stale-client heuristic 2026-05-08 13:12:16 +08:00
Frank Song
b684317554 test: parametrize kanban double-404 guard across HTTP methods 2026-05-08 12:48:23 +08:00
Nathan Esquenazi
f3b56d8793 fix(kanban): avoid double 404 when bridge already sent error response
PR #1837's new `_kanban_unknown_endpoint` wrapper was triggered for any
falsy bridge return — but `handle_kanban_*` returns `None` (not `True`)
when an inner handler calls `bad(...)` to send an error response. The
wrapper then sent a SECOND 404 on top of the bridge's response, producing
concatenated JSON bodies on the wire.

Concrete reproducer (caught by behavioural harness, not the merged tests):

    GET /api/kanban/tasks/<missing-id>/log
    →  '{"error":"task not found"}{"error":"unknown Kanban endpoint: GET ..."}'

This affected every `bad(...)`-shaped error path in the bridge:
- task-not-found returns from `_task_log_payload` / `_task_detail_payload`
- exception handlers for ImportError (503), LookupError (404),
  ValueError (400), RuntimeError (409) across all four method handlers
- the `_handle_events_sse_stream` board-resolution failure path

The fix: distinguish an explicit `False` (truly unmatched path) from
`None` (handled, response already sent). Only `False` should trigger
the unknown-endpoint diagnostic.

Adds a regression test that exercises the task-not-found path through
`routes.handle_get` and asserts only one JSON body is on the wire.

Follow-on to #1837 (already merged into master at v0.51.20).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 11:35:57 -07:00
Michael Lam
bb75707331 fix: surface stale Kanban client recovery 2026-05-07 17:57:09 +00:00