Skip to content

feat(sdk): résilience & coût de l'enregistrement replay #12

Description

@DorianOuvrard

Contexte

Audit SDK + diagnostic frame-loss : aujourd'hui un chunk perdu tôt casse tout le replay (un seul FullSnapshot initial), et on enregistre 100 % des sessions (pas de sampling).

Scope

  • Full-snapshot périodique via checkoutEveryNms (~5 min) → borne la casse d'un chunk perdu à une fenêtre + permet le seek.
  • Sampling session (%).
  • Capture on-error (ring buffer) pour garantir les sessions en erreur à coût maîtrisé.

Références

rrweb checkoutEveryNms ; PostHog full_snapshot_interval_millis:300000 ; Sentry replaysSessionSampleRate / replaysOnErrorSampleRate + buffer mode.

Effort : M — Valeur : Moyen-Haut. Complémentaire du fix transport beacon (workstream séparé).


Sources d'analyse. Née d'un audit de conception du SDK @bworlds/launchkit v1.15.0 vs état de l'art (benchmark open-source de la capture d'infos).
Références comparées en source réelle : rrweb (rrweb-io/rrweb), PostHog (PostHog/posthog-js), Sentry (getsentry/sentry-javascriptpackages/browser, packages/replay-internal), OpenReplay (openreplay/openreplay), Datadog RUM (DataDog/browser-sdk), Grafana Faro (grafana/faro-web-sdk), lib GoogleChrome/web-vitals. Contrainte transport (plafond 64 KiB partagé sendBeacon/keepalive) : Fetch spec + Sentry #1464.
Note honnêteté : la CSP est vérifiée chez Faro (enableContentSecurityPolicyInstrumentation), pas Sentry ; les défauts PostHog dead-clicks/exceptions sont remote-config-gated (non hardcodés).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions