A notification endpoint that answered with a redirect was counted as delivered. Only a status of 400 or more counted as a failure, and the request is sent straight through the transport rather than an HTTP client, so a 301, 302 or 307 is never followed. The delivery was not retried or logged, and the notification never arrived.
sendNtfy and sendSlack (which also sends to Mattermost) now treat any status outside 200-299 as a failed delivery. It is retried and logged like a network error or a 5xx. The constant that named 400 is gone; the check uses the standard library's status names.
New test: a local test server answers 302 to ntfy, Slack and Mattermost. It must receive each endpoint's first attempt and its retry, and each endpoint must log its retry line and then failed to send notification after retries, with the 302 in the error. That log check was already written out in the connection-refused test, so it now lives in one helper that both tests call.
README, Notifications, now says a delivery fails on "an HTTP status other than 2xx". The sendSlack doc comment was the only other place that said which statuses fail; it is updated to match.
Judgement call: the redirect is still not followed. Following a 301 or 302 would turn the POST into a GET and drop the notification body.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/dnswatcher/issues/287.
A notification endpoint that answered with a redirect was counted as delivered. Only a status of 400 or more counted as a failure, and the request is sent straight through the transport rather than an HTTP client, so a `301`, `302` or `307` is never followed. The delivery was not retried or logged, and the notification never arrived.
`sendNtfy` and `sendSlack` (which also sends to Mattermost) now treat any status outside 200-299 as a failed delivery. It is retried and logged like a network error or a `5xx`. The constant that named 400 is gone; the check uses the standard library's status names.
New test: a local test server answers `302` to ntfy, Slack and Mattermost. It must receive each endpoint's first attempt and its retry, and each endpoint must log its retry line and then `failed to send notification after retries`, with the 302 in the error. That log check was already written out in the connection-refused test, so it now lives in one helper that both tests call.
README, Notifications, now says a delivery fails on "an HTTP status other than 2xx". The `sendSlack` doc comment was the only other place that said which statuses fail; it is updated to match.
Judgement call: the redirect is still not followed. Following a `301` or `302` would turn the POST into a GET and drop the notification body.
Model: opus-5-5
A notification endpoint that answered with a redirect was counted as
delivered: the request is not sent through a client, so the redirect
is never followed, and only a status of 400 or more counted as a
failure. Now any status outside 200-299 fails the delivery for ntfy,
Slack and Mattermost, so it is retried and logged like the others.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #287.
A notification endpoint that answered with a redirect was counted as delivered. Only a status of 400 or more counted as a failure, and the request is sent straight through the transport rather than an HTTP client, so a
301,302or307is never followed. The delivery was not retried or logged, and the notification never arrived.sendNtfyandsendSlack(which also sends to Mattermost) now treat any status outside 200-299 as a failed delivery. It is retried and logged like a network error or a5xx. The constant that named 400 is gone; the check uses the standard library's status names.New test: a local test server answers
302to ntfy, Slack and Mattermost. It must receive each endpoint's first attempt and its retry, and each endpoint must log its retry line and thenfailed to send notification after retries, with the 302 in the error. That log check was already written out in the connection-refused test, so it now lives in one helper that both tests call.README, Notifications, now says a delivery fails on "an HTTP status other than 2xx". The
sendSlackdoc comment was the only other place that said which statuses fail; it is updated to match.Judgement call: the redirect is still not followed. Following a
301or302would turn the POST into a GET and drop the notification body.Model: opus-5-5
Passes review; needs a rebase onto
nextforTODO.mdalone.Model: opus-5-5
a1caf4914ctofafb53da35