Sentry Backend Modification for SSR Traces

Start with the Span Links Spec and the referenced sentry/search/eap/spans/attributes.py entry point, then review how Relay and the span consumer pass links into EAP. Done means the project has a decided, queryable approach for linking cached server and client traces, including supported directions and cache-lifetime query windows, or a documented attribute workaround if indexed links are not feasible.

The Problem: Cached SSR pages have no connected client/server trace

SSR meta-frameworks cache the HTML/render output: a server renders a page once (build-time, first visit, or on revalidation). Later visitors get the stored result from the server (so no server trace or a disconnected one).
Probably thousands of client pageloads map to one server render.

Differences to previous_trace linking

• previous_trace is a 1:1 relationship
• Cached server pages are 1 origin with many consumers (1:N)
• Time-gap between server and client can be as long as the cache lifetime

What exists

• Span Links Spec: https://develop.sentry.dev/sdk/telemetry/traces/span-links/
• Relay has full support for span links (sentry.links and sentry.link.type) and passes them through untouched
• Span consumer flattens each span link(s) into a JSON attribute sentry.links - stored in EAP
• sentry.links is not queryable (private=True)
• Span Attribute support for previous_trace

What we need

1. Span links, queryable in EAP - indexed by trace_id in both directions
   • Prio 1: One of multiple, different consuming traces (e.g. browser pageload trace) should be able to link to the one connecting server trace
   • Prio 2: Also nice: One cached server trace should be able to link to all the client/browser traces it served
     • What is the cost of this query?
     • Can we get an aggregate (e.g. just the number) of it?
2. Workaround (near-term solution): Register a queryable attribute (similar to previous_trace - here in code)
   • we only need this workaround if the task above (links in EAP) takes too long
   • Only works for N:1 lookup (like Prio 1 task from above)
   • Example naming: simple_sentry_field("cache_origin_trace")
   • Can we do a 1:N lookup with this attribute?
3. Querying Time Window
   • Being able to query links within a window that fits cache lifetimes (not assumptions of e.g. 1 hour windows)
   • What are possible limitations here?