sneak
e65cb89d1c
All checks were successful
check / check (push) Successful in 3m26s
max_retries was read through parseNonNegativeInt, which returned 0 for any parse failure. On the create form `abc`, `2.7`, `-5` and a twenty-digit number were all accepted with HTTP 200 and stored as 0, and `999999999` was stored verbatim with no ceiling. On the edit form the same input destroyed a working retry configuration: a target delivering with max_retries=2, re-saved with a typo in the field, was silently left at 0 — fire-and-forget on a store-and-forward proxy, with nothing said. A value that is set but unparseable must be rejected loudly. A default belongs only to an absent value. parseMaxRetries makes that distinction explicit: an empty or omitted field yields the caller's fallback (0 at creation, the stored count on edit), and anything else that is not a whole number in range is a 400. Both forms go through one validator, so they cannot come to disagree. The ceiling is 20, which both target templates have always declared as max="20" on the input; only the server never enforced it. Backoff is 2^(n-1) seconds, so attempt 20 is already about six days out, and each attempt writes a delivery_results row the event log then loads and renders. The rejection wording matches the timeout control on the same submission, which already got this right, and names the ceiling when the value is out of range. Existing rows above the ceiling are untouched: they still render on the source and edit pages and still deliver. This is input validation, not a migration. parseNonNegativeInt is removed. Its other two callers read the log page number for a post-action redirect, where falling back to page 1 is correct — it is navigation, not stored configuration, and the action has already completed. They now use pageOrFirst, named for what it does and shared with parsePage on the GET side, so no general silently-coercing int parser is left for a configuration field to reach for.
6.4 KiB
6.4 KiB