With SENTRY_DSN set, the server initialises sentry-go with the release netwatch-server- followed by its version, and adds the sentryhttp middleware with Repanic: true: a panic in a handler is reported to that Sentry project, and the panic recovery still answers 500. On shutdown it waits up to 2 seconds for Sentry to finish sending. A DSN Sentry refuses stops the start with an error naming SENTRY_DSN. With it empty, Sentry is never set up. Both READMEs list the setting.
What the diff does not show:
sentry.Init sets Sentry's client for the whole process, so TestSentry covers the empty and the set case in one test and unsets the client when it ends.
TestSentry waits up to 5 seconds for the local stand-in for Sentry to receive the report instead of calling sentry.Flush: a flush right after the panic can return before sentry-go's own goroutine has queued the report.
The test's panicking route is added through Router() in export_test.go; the server itself has no such route.
Judgement call: the Sentry middleware is the last router-wide middleware, after the timeout, as the conventions order it; the metrics middleware stays on the matched routes, where #103 put it, so it now runs inside the Sentry middleware instead of before it.
Unverified: delivery to a real Sentry project over HTTPS; the tests use a local stand-in.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/netwatch/issues/95.
With `SENTRY_DSN` set, the server initialises `sentry-go` with the release `netwatch-server-` followed by its version, and adds the `sentryhttp` middleware with `Repanic: true`: a panic in a handler is reported to that Sentry project, and the panic recovery still answers 500. On shutdown it waits up to 2 seconds for Sentry to finish sending. A DSN Sentry refuses stops the start with an error naming `SENTRY_DSN`. With it empty, Sentry is never set up. Both READMEs list the setting.
What the diff does not show:
- `sentry.Init` sets Sentry's client for the whole process, so `TestSentry` covers the empty and the set case in one test and unsets the client when it ends.
- `TestSentry` waits up to 5 seconds for the local stand-in for Sentry to receive the report instead of calling `sentry.Flush`: a flush right after the panic can return before `sentry-go`'s own goroutine has queued the report.
- The test's panicking route is added through `Router()` in `export_test.go`; the server itself has no such route.
- `sentry-go` was added through `make tidy` from https://git.eeqj.de/sneak/netwatch/issues/45.
Disclosures:
- Judgement call: the Sentry middleware is the last router-wide middleware, after the timeout, as the conventions order it; the metrics middleware stays on the matched routes, where https://git.eeqj.de/sneak/netwatch/pulls/103 put it, so it now runs inside the Sentry middleware instead of before it.
- Unverified: delivery to a real Sentry project over HTTPS; the tests use a local stand-in.
Model: opus-5-5
With SENTRY_DSN set, the server initialises sentry-go with the release
netwatch-server-<version>, adds the sentryhttp middleware with Repanic
as the last router-wide middleware, after the timeout, and flushes
Sentry for 2 seconds on shutdown. A DSN Sentry refuses stops the start
with an error naming SENTRY_DSN. With it empty, nothing is set up.
The metrics middleware stays on the matched routes only, so it runs
inside the Sentry middleware rather than before it.
Model: opus-5-5
PASS: with SENTRY_DSN set, Sentry starts under the release netwatch-server- plus the version, sentryhttp with Repanic: true is the last router-wide middleware as the conventions order it, shutdown waits up to 2 seconds for Sentry, and a refused DSN stops the start naming SENTRY_DSN; with it empty nothing is set up and the container sends nothing out; the test, both READMEs and TODO.md meet the definition of done in #95.
Model: opus-5-5
PASS: with `SENTRY_DSN` set, Sentry starts under the release `netwatch-server-` plus the version, `sentryhttp` with `Repanic: true` is the last router-wide middleware as the conventions order it, shutdown waits up to 2 seconds for Sentry, and a refused DSN stops the start naming `SENTRY_DSN`; with it empty nothing is set up and the container sends nothing out; the test, both READMEs and `TODO.md` meet the definition of done in https://git.eeqj.de/sneak/netwatch/issues/95.
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.
Closes #95.
With
SENTRY_DSNset, the server initialisessentry-gowith the releasenetwatch-server-followed by its version, and adds thesentryhttpmiddleware withRepanic: true: a panic in a handler is reported to that Sentry project, and the panic recovery still answers 500. On shutdown it waits up to 2 seconds for Sentry to finish sending. A DSN Sentry refuses stops the start with an error namingSENTRY_DSN. With it empty, Sentry is never set up. Both READMEs list the setting.What the diff does not show:
sentry.Initsets Sentry's client for the whole process, soTestSentrycovers the empty and the set case in one test and unsets the client when it ends.TestSentrywaits up to 5 seconds for the local stand-in for Sentry to receive the report instead of callingsentry.Flush: a flush right after the panic can return beforesentry-go's own goroutine has queued the report.Router()inexport_test.go; the server itself has no such route.sentry-gowas added throughmake tidyfrom #45.Disclosures:
Model: opus-5-5
PASS: with
SENTRY_DSNset, Sentry starts under the releasenetwatch-server-plus the version,sentryhttpwithRepanic: trueis the last router-wide middleware as the conventions order it, shutdown waits up to 2 seconds for Sentry, and a refused DSN stops the start namingSENTRY_DSN; with it empty nothing is set up and the container sends nothing out; the test, both READMEs andTODO.mdmeet the definition of done in #95.Model: opus-5-5