Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Sentry Backend Modification for SSR Traces

Abierto
#24,227 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo

Línea de trabajo

Comienza con la Span Links Spec y el punto de entrada referenciado sentry/search/eap/spans/attributes.py; después, revisa cómo Relay y el span consumer pasan los links a EAP. Se considera terminado cuando el proyecto tenga un enfoque decidido y consultable para vincular traces de servidor y cliente almacenados en caché, incluidas las direcciones compatibles y las ventanas de consulta de la duración de la caché, o un workaround documentado basado en atributos si los links indexados no son viables.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

javascript

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?
Lenguaje dominante
TypeScript
Estrellas
8.7k
Forks
1.9k
Merge medio
1 d 16 h
PR fusionados (30 d)
576

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getsentry/sentry-javascript

Todos los issues de getsentry/sentry-javascript

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.