What's the problem?
Today only logs at level error (and above) are forwarded to Sentry by @contextbridge/instrumentation. Warnings — which often indicate degraded behavior or conditions that precede a real error — stay local in stderr and never reach Sentry. As a result, we lose early signals about issues users hit in real usage and can only react after something has hard-failed.
Proposed solution
Lower the pino → Sentry capture threshold so warn-level logs are also reported, mapped to Sentry's warning severity so they remain filterable and don't drown out true errors.
Additional context
ContextBridge is a local-first tool, so telemetry sensitivity matters. Prior discussion concluded that warn-level reporting is acceptable in principle, but the rollout should:
- Audit existing
logger.warn(...) call sites to confirm no user-supplied content (file paths, markdown bodies, plan text, etc.) is attached to the structured log object.
- Establish a convention for future warn-level logs so the same payload-hygiene rule applies going forward.
What's the problem?
Today only logs at level
error(and above) are forwarded to Sentry by@contextbridge/instrumentation. Warnings — which often indicate degraded behavior or conditions that precede a real error — stay local in stderr and never reach Sentry. As a result, we lose early signals about issues users hit in real usage and can only react after something has hard-failed.Proposed solution
Lower the pino → Sentry capture threshold so
warn-level logs are also reported, mapped to Sentry'swarningseverity so they remain filterable and don't drown out true errors.Additional context
ContextBridge is a local-first tool, so telemetry sensitivity matters. Prior discussion concluded that warn-level reporting is acceptable in principle, but the rollout should:
logger.warn(...)call sites to confirm no user-supplied content (file paths, markdown bodies, plan text, etc.) is attached to the structured log object.