The webhook handler's client had no timeout, and slog calls the handler inside the log call, so a server that accepted the connection and never answered stopped that log call for good, and every later one. A request still running after 5 seconds, reading the answer included, now fails with a timeout error. The handler also reads the answer to the end before closing it, so the connection is reused for the next record. Two new tests point the handler at a server that never answers and at one that sends its status and then stalls the answer, and check that Handle returns a timeout error within the timeout. The README states the timeout. Model: opus-5-5
This commit was merged in pull request #39.
This commit is contained in:
@@ -116,7 +116,9 @@ the record:
|
||||
stdout, wrapped, so `errors.Is` still matches the original
|
||||
- `WebhookHandler` returns an error when the request fails, and also when
|
||||
the server answers with a status outside 2xx, a redirect included,
|
||||
since it does not follow redirects
|
||||
since it does not follow redirects. A request that has not finished
|
||||
after 5 seconds fails with a timeout error, so a webhook server that
|
||||
never answers holds up a log call for 5 seconds at most
|
||||
- `MultiplexHandler`, which simplelog installs as the default, passes the
|
||||
record to every handler it holds even after one of them fails, then
|
||||
returns all their errors joined with `errors.Join` (nil if none failed)
|
||||
|
||||
Reference in New Issue
Block a user