Sentry Backend Modification for SSR Traces

Span Links Spec と参照されているエントリーポイント sentry/search/eap/spans/attributes.py から始め、Relay と span consumer がどのようにリンクを EAP に渡すかを確認します。プロジェクトで、キャッシュされたサーバーとクライアントのトレースをリンクするための、方針が決定されクエリ可能なアプローチ（サポートされる方向とキャッシュ有効期間に基づくクエリウィンドウを含む）が定まっているか、インデックス化されたリンクが実現できない場合の属性による workaround が文書化されていれば完了です。

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?