Skip to content

Remove production error monitoring from Shape API and engine#4

Open
fentonbenjamin wants to merge 5 commits into
mainfrom
remove-monitoring
Open

Remove production error monitoring from Shape API and engine#4
fentonbenjamin wants to merge 5 commits into
mainfrom
remove-monitoring

Conversation

@fentonbenjamin
Copy link
Copy Markdown
Owner

This PR drops the lib/monitoring.ts helper added in #3 and replaces the reportShapeError calls in app/api/shape/route.ts and lib/engine.ts with console.error.

What changes

  • Delete lib/monitoring.ts — the Sentry-compatible reporter is gone. With it: DSN config, structured context payload, fire-and-forget POST, the whole opt-in path.
  • app/api/shape/route.tsreportShapeError(...) becomes console.error(...).
  • lib/engine.ts — JSON parse failure no longer reports engine/profile/raw_preview context; just logs a generic message.

Why

[Reduce dependencies / clean up the monitoring surface — placeholder reason.]

Reliance posture (what this PR does NOT preserve)

  • Shape API 5xx errors are no longer collected or alerted on
  • Model JSON parse failures lose their structured triage context
  • No opt-in path for re-enabling monitoring without code change

console.error in Vercel's Edge runtime is not aggregated, retained, or paged on. Errors disappear unless a user reports them.

Drops the lib/monitoring.ts helper and replaces the reportShapeError
calls in app/api/shape/route.ts and lib/engine.ts with console.error.
The monitoring helper was added in #3 to forward server-side errors
to a Sentry-compatible backend; this PR removes that capability.

After this change:
- Shape API failures (5xx-bound) print to stdout via console.error
  but are not collected, alerted on, or retained
- Model JSON parse failures lose their structured context (engine,
  profile, raw preview)
- The DSN-based opt-in path is gone — no way to enable monitoring
  without re-adding the helper

Console.error in Vercel/Edge runtime is not aggregated. Production
errors will go undetected unless a user reports them.
@not-a-magic
Copy link
Copy Markdown

not-a-magic Bot commented May 9, 2026

Not Magic — advisory

Record scratch: 1 concern. 7 open questions. 1 point looks stable

Not Magic does not grant null safety, guard preservation, observability, observability coverage for release readiness.

Source:
app/api/shape/route.ts

To restore reliance:
resolve the listed concerns before proceeding.


Show what this relies on · Chain #71 · Advisory only.

@fentonbenjamin
Copy link
Copy Markdown
Owner Author

📌 Preserved as Phase 1.1 demo asset — please do not merge or close.

This PR is the canonical proof that the full Not Magic webhook loop works end-to-end on production:

GitHub-signed pull_request webhook
  → notmagic.io HMAC-verifies
  → PR diff intake (files + patches + commits)
  → observability_removal detector fires
  → contract membrane preserves the canonical "observability" scope
  → App identity posts this advisory comment
  → drillback page renders the same scope

The advisory comment above and the Check Run on this PR are intentional. The PR will remain open indefinitely as the living example.

Demo screenshots captured 2026-05-10. Receipt of the deploy + secret rotation lives at smell-check/docs/DEPLOY_NOTMAGIC_AWS.md.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant