Files
Daoyuan LiandGitHub 9a5d701355 fix(channels): document GitHub dedupe TTL, tighten redelivery tests (#4274)
* fix(channels): document GitHub dedupe TTL, tighten redelivery tests

Follow-up to PR #4104's review, whose non-blocking notes were left
unaddressed at merge time:

- Document the previously-undocumented inbound-dedupe TTL
  (INBOUND_DEDUPE_TTL_SECONDS, 10 min, in-memory only) directly above
  the constant in ChannelManager: what it is, why the window, and what
  happens at the boundary (a manual "Redeliver" clicked after the TTL
  has elapsed, or any redelivery after a Gateway restart, is not
  deduped, since _recent_inbound_events is never persisted to
  ChannelStore). Cross-reference it from the GitHub dispatcher's
  fan-out comment, which previously implied unconditional redelivery
  coverage.
- test_channels.py::test_github_redelivery_is_deduped_like_other_channels:
  the _gh helper stamped a 2-part delivery:agent id while production
  stamps a 3-part delivery:user:agent id. Align the helper with the
  real shape and add a cross-user assertion the old 2-part shape could
  not even express.
- test_github_dispatcher.py::test_missing_delivery_header_leaves_dedupe_open:
  previously only asserted the dispatcher-layer id was None. Add the
  manager-level _is_duplicate_inbound assertion across two header-less
  deliveries so a future regression that treats a missing id as a real
  key is caught here too, not only at the dispatcher layer.

All four affected test files (test_github_dispatcher.py,
test_channels.py, test_github_channel.py, test_github_registry.py)
pass; ruff check and ruff format --check are clean. Verified the two
tightened tests actually discriminate by temporarily reintroducing
each bug they target (2-part id shape; missing-id treated as a real
key) and confirming the new assertions fail, then reverting.

* fix(channels): correct GitHub redelivery claim in dedupe comments

fancyboi999's review on this PR flagged that the previous commit's new
comments (manager.py, dispatcher.py) justified the 10-minute dedupe TTL
by claiming GitHub automatically retries a failed delivery after its
10-second timeout. GitHub's own documentation says the opposite:
failed deliveries (non-2xx, timeout, connection error) are recorded as
failed and never automatically redelivered, for both repository and
GitHub App webhooks alike. Every redelivery is explicit: the "Redeliver"
button, the REST API, or an operator's own recovery script.

- manager.py: rework the INBOUND_DEDUPE_TTL_SECONDS comment to state
  GitHub's actual behavior (no auto-retry), cite the authoritative doc
  (docs.github.com/en/webhooks/using-webhooks/handling-failed-webhook-deliveries),
  and justify the 10-minute window as a bound on explicit near-term
  replays rather than an automatic-retry window. No longer asserts
  unverified retry behavior for the other channels either.
- dispatcher.py: same correction for the dedupe_message_id comment,
  which previously implied "retried after a timeout" as a distinct,
  automatic case alongside the manual "Redeliver" button.
- test_channels.py / test_github_dispatcher.py: reworded the two
  docstrings and one section comment that repeated the same
  "retry-on-timeout" framing, so the corrected mental model doesn't
  sit next to contradicting prose nearby. No assertions changed.

Verified directly against GitHub's current documentation (fetched, not
paraphrased from memory): "Handling failed webhook deliveries" states
plainly that GitHub does not auto-redeliver; "Automatically redelivering
failed deliveries for a GitHub App webhook" / "...for a repository
webhook" are both guides for a user-written recovery script (GitHub's
own example runs on a 6-hour cron), not a native GitHub feature. No
difference in this behavior between GitHub Apps and repository webhooks.

All four affected test files pass; the two `test_bot_login_whitespace_only`
/ `test_trigger_mention_login_whitespace_only` failures in
test_github_dispatcher.py are pre-existing on this branch's unmodified
HEAD (confirmed against a clean checkout of the same commit) and are
unrelated to this change. ruff check and ruff format --check are clean
on all four touched files.
2026-07-19 22:08:48 +08:00
..