Say max_retries is the total attempt count, not a retry count #320

Merged
clawbot merged 1 commits from issue-316-max-retries-total-attempts-copy into next 2026-09-21 18:33:10 +02:00
Collaborator

Both target forms (create and edit) and the README max_retries rows now say the number is the total number of delivery attempts, not retries added to a first try.

Why: the delivery core makes max_retries attempts in total — a new delivery starts at attempt one and stops once the attempt number reaches max_retries — so 3 means three attempts and 0 is a single fire-and-forget attempt with no retries and no circuit breaker. The forms said "Max retries" with no total and the README row said "maximum retry attempts", so an operator wanting "try, then retry twice" would enter the wrong number.

What changed: the help text under the field on both forms, the max_retries table row and the http description in the README, and a UI copy test that renders both forms and pins the shared wording. Delivery arithmetic unchanged.

Verification: make fmt-check and the new copy test pass. Full make check could not be made green here — the shared host is out of memory (load ~320; every -race build OOM-killed), so make check and make lint were killed before finishing. The one run that reached the test phase passed everything except two argon2 login subtests in internal/handlers that hit the 90s per-package timeout under that load, a known timing-marginal package (#194) unrelated to this change.

Disclosure: make check not confirmed green and make lint unverified, both due to host OOM; lowered parallelism (-p=1 -parallel=2, GOMAXPROCS=6) did not help — saturation is host-wide.

Model: opus-4-8

Both target forms (create and edit) and the README `max_retries` rows now say the number is the total number of delivery attempts, not retries added to a first try. Why: the delivery core makes `max_retries` attempts in total — a new delivery starts at attempt one and stops once the attempt number reaches `max_retries` — so `3` means three attempts and `0` is a single fire-and-forget attempt with no retries and no circuit breaker. The forms said "Max retries" with no total and the README row said "maximum retry attempts", so an operator wanting "try, then retry twice" would enter the wrong number. What changed: the help text under the field on both forms, the `max_retries` table row and the `http` description in the README, and a UI copy test that renders both forms and pins the shared wording. Delivery arithmetic unchanged. Verification: `make fmt-check` and the new copy test pass. Full `make check` could not be made green here — the shared host is out of memory (load ~320; every `-race` build OOM-killed), so `make check` and `make lint` were killed before finishing. The one run that reached the test phase passed everything except two argon2 login subtests in `internal/handlers` that hit the 90s per-package timeout under that load, a known timing-marginal package (https://git.eeqj.de/sneak/webhooker/issues/194) unrelated to this change. Disclosure: `make check` not confirmed green and `make lint` unverified, both due to host OOM; lowered parallelism (`-p=1 -parallel=2`, `GOMAXPROCS=6`) did not help — saturation is host-wide. Model: opus-4-8
clawbot added the needs-review label 2026-09-21 09:56:33 +02:00
clawbot self-assigned this 2026-09-21 09:56:33 +02:00
Author
Collaborator

Pass: the help text on both target forms and the README max_retries rows now matches the delivery arithmetic (0 is a single fire-and-forget attempt, N is N attempts in total, a fresh delivery starting at attempt 1 and giving up once the attempt number reaches max_retries), the copy test genuinely pins that wording (a mutation of the form text fails it), and make check including lint is green on the head rebased onto current next.

Model: opus-4-8

Pass: the help text on both target forms and the README `max_retries` rows now matches the delivery arithmetic (0 is a single fire-and-forget attempt, N is N attempts in total, a fresh delivery starting at attempt 1 and giving up once the attempt number reaches `max_retries`), the copy test genuinely pins that wording (a mutation of the form text fails it), and `make check` including lint is green on the head rebased onto current `next`. Model: opus-4-8
clawbot added 1 commit 2026-09-21 18:29:21 +02:00
The delivery core makes max_retries attempts in total: a fresh delivery
starts at attempt one and gives up once the attempt number reaches
max_retries, so 3 is three attempts, not four, and 0 is special-cased to
a single fire-and-forget attempt with no retries and no circuit breaker.
The create and edit target forms called it "Max retries" with no total,
and the README data-model row called it "maximum retry attempts", so an
operator wanting "try, then retry twice" would enter the wrong number.

Both forms and the README rows now state the number is the total number
of delivery attempts, with the 0 case spelled out. The delivery
arithmetic is unchanged. A UI copy test renders both forms and pins the
shared wording so it cannot drift back to a retry count.

Model: opus-4-8
clawbot force-pushed issue-316-max-retries-total-attempts-copy from 433fdceee2 to 5822f0f7b0 2026-09-21 18:29:21 +02:00 Compare
clawbot merged commit b051821370 into next 2026-09-21 18:33:10 +02:00
clawbot deleted branch issue-316-max-retries-total-attempts-copy 2026-09-21 18:33:10 +02:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/webhooker#320