Frontend Error Trace Id

Frontend Error Display — Show X-Trace-ID

When the UI surfaces an error and the failing response carries an X-Trace-ID response header, the trace id MUST be shown as part of the error display (toast / inline error / error boundary) so a user can quote it for support + the dev can jump straight to the trace in SigNoz.

Pairs with frontend-conventions.md (error surfaces) and the signoz-debug skill (trace-first debugging — the id shown here is the entry point).

Always SHOW the trace id for

• Server errors — 5xx, network/Worker failures, anything unexpected.
• Business-logic errors — domain rule rejections from @packages/service (state-machine guard, settlement/billing invariant, permission denial, etc.).
• Data errors NOT bound to a form field — record missing, stale/conflict, or duplicate detected away from a form input (e.g. a list/detail/action flow, a background refetch, a bulk operation). If it isn’t a field the user is editing, it gets the trace id.

NEVER show the trace id for

• Public / unauthenticated pages — login, register (if one exists), any pre-auth page. No trace id on these, ever.
• Form-input validation errors — client-side Zod / required / format failures on the user’s own input.
• Form-field uniqueness conflicts — a DB-unique violation surfaced inline on the offending input (e.g. duplicate slug, email already taken). The fix is “change the field”, not “file a trace” → no trace id.

The split is position, not error type: the same “duplicate” condition shows a trace id when it surfaces in a non-form context but is silent when surfaced on the form field the user can fix.

How

• Read the id from the X-Trace-ID response header of the failing request.
• Render it as a de-emphasised, copyable suffix of the error display (e.g. small monospace Trace: 7f3c…), not the primary message.
• No header present → show the error normally, no trace line.