Skip to content

ops: error tracking and session diagnostics #76

Description

@joelpeace48-cell

Problem

Client-side errors are invisible. A wallet connection that fails for a specific
browser or extension version, or a dashboard that throws on an edge-case data
shape, will simply be experienced as "the site is broken" with no signal
reaching anyone who could fix it.

What to do

  • Integrate Sentry or an equivalent, capturing client and server errors with
    source maps uploaded at build time — a minified stack trace is not
    actionable.
  • Wire it into the error.tsx and global-error.tsx boundaries.
  • Scrub aggressively before sending: no wallet addresses, no request bodies, no
    anything that identifies a user. This is a privacy-forward product and the
    error tracker must not become the leak.
  • Tag events with release version and commit SHA so a regression is traceable
    to a deploy.
  • Alert on error-rate spikes rather than individual events.

Acceptance criteria

  • Client and server errors captured with source maps
  • Wired into both error boundaries
  • PII and wallet data scrubbed, verified by a test
  • Releases tagged with commit SHA
  • Rate-based alerting configured

Notes

Write the scrubbing test as an assertion that a known address string never
appears in a captured payload. It is the only form of this that stays true as
the codebase changes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSThird CampaignCampaign: Third Campaignarea:opsSEO, analytics, CIdifficulty:mediumFamiliar patterns; touches a few files or conceptspriority:mediumValuable, not blockingtype:choreTooling, CI, dependencies

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions