@beignet/provider-error-reporting-sentry 0.0.21 → 0.0.22
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +6 -0
- package/README.md +24 -1
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
package/README.md
CHANGED
|
@@ -8,7 +8,7 @@ keeping Sentry imports out of contracts, use cases, routes, and domain code.
|
|
|
8
8
|
## Install
|
|
9
9
|
|
|
10
10
|
```bash
|
|
11
|
-
bun add @beignet/provider-error-reporting-sentry @sentry/node
|
|
11
|
+
bun add @beignet/provider-error-reporting-sentry @beignet/core @sentry/node
|
|
12
12
|
```
|
|
13
13
|
|
|
14
14
|
## Register
|
|
@@ -31,6 +31,10 @@ With no `dsn` or `SENTRY_DSN`, the provider still contributes the Beignet port
|
|
|
31
31
|
but does not initialize Sentry. This is useful for examples and local apps that
|
|
32
32
|
want stable wiring before production secrets exist.
|
|
33
33
|
|
|
34
|
+
`beignet doctor --strict` checks that installed Sentry providers are registered
|
|
35
|
+
in `server/providers.ts`. `SENTRY_DSN` is optional by metadata because local and
|
|
36
|
+
example apps may intentionally run with a no-op Sentry client.
|
|
37
|
+
|
|
34
38
|
## Capture HTTP failures
|
|
35
39
|
|
|
36
40
|
Register `createErrorReportingHooks(...)` in `server/index.ts` so unexpected
|
|
@@ -102,3 +106,22 @@ Creates a Beignet lifecycle provider that contributes:
|
|
|
102
106
|
|
|
103
107
|
Ready-to-register provider using the default Sentry singleton and
|
|
104
108
|
`process.env.SENTRY_DSN` when present.
|
|
109
|
+
|
|
110
|
+
## Failure behavior
|
|
111
|
+
|
|
112
|
+
`captureException(...)` and `captureMessage(...)` resolve after handing work to
|
|
113
|
+
Sentry's SDK. With no configured DSN, the Beignet port is still present and
|
|
114
|
+
capture calls become local no-ops apart from Beignet instrumentation. SDK
|
|
115
|
+
transport failures follow Sentry's buffering and delivery behavior.
|
|
116
|
+
|
|
117
|
+
## Local and tests
|
|
118
|
+
|
|
119
|
+
Leave `SENTRY_DSN` unset locally when you only need stable app wiring. Use a
|
|
120
|
+
fake `ErrorReporterPort` in use-case tests and assert error-reporting hooks at
|
|
121
|
+
the route/server boundary when the reporting behavior matters.
|
|
122
|
+
|
|
123
|
+
## Deployment notes
|
|
124
|
+
|
|
125
|
+
Set `SENTRY_DSN` and Sentry environment/release metadata per deployed
|
|
126
|
+
environment. Register `createErrorReportingHooks(...)` in `server/index.ts` if
|
|
127
|
+
HTTP/server failures should be captured automatically.
|