Sentry Backend Modification for SSR Traces

从 Span Links Spec 和所引用的入口点 sentry/search/eap/spans/attributes.py 开始，然后检查 Relay 和 span consumer 如何将链接传递给 EAP。完成的标准是：项目已经确定了一种可查询的方案，用于关联缓存的服务器和客户端 traces，其中包括支持的方向以及按缓存生命周期划分的查询窗口；如果无法实现索引化链接，则应记录一种基于属性的 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?