Tracking: a retried event is stored twice, so revenue and count metrics double-count it

Abierto
  • ¿Algo no está bien?
#1,543 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
python
Área
analytics, api, backend, database

Línea de trabajo

Start with the event request schema in backend/app/schemas/tracking.py (around line 392), the events table in backend/app/models/event.py (lines 126-138), and the metric queries in AnalysisService.value_totals and event_counts in backend/app/services/analysis_service.py. The approach is not decided yet, so first get a maintainer decision on the event-id design. Done would mean a regression test that posts the same purchase twice to /track and shows revenue per user counts it once.

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

Descripción

bug

What happens

POST /api/v1/tracking/track and POST /api/v1/tracking/batch store every event they receive, and nothing identifies an event across requests:

  • EventRequest (backend/app/schemas/tracking.py:392) has no event-id field;
  • events.id is generated by the server;
  • the events table has plain indexes only, with no unique constraint (backend/app/models/event.py:126-138).

So a client that retries after a timeout stores the event twice whenever the first request was in fact stored.

What it changes in results

  • Revenue metrics sum Event.value per user (AnalysisService.value_totals, backend/app/services/analysis_service.py:311), so a retried purchase counts twice.
  • Count metrics count every stored event (AnalysisService.event_counts, analysis_service.py:276), so they double too.
  • Conversion rates are unaffected, because they count distinct users.
  • Assignments are unaffected, because /assign is idempotent through the unique (experiment_id, user_id) index.

The error isn't the same in both arms. The arm whose clients retry more, for example a slower variant, gets more duplicates, which biases the comparison and doesn't just add noise.

Evidence

Read in the code at main d48e06c. It has not been reproduced by a run yet. The fix's regression test should do that: send the same purchase twice through /track, and check that revenue per user counts it once.

Direction (to be planned, not decided)

The usual pattern is an optional event id supplied by the client, deduplicated per user, in the manner of an idempotency key. That needs a migration, an API contract change and SDK changes, so it goes through the full process. It is also the first fault scenario for the ground-truth replay tests in #1544.

Lenguaje dominante
Python
Estrellas
0
Forks
4
Merge medio
5 h 36 min
PR fusionados (30 d)
509

Preparar el entorno

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 Controlvar/controlvar

Todos los issues de Controlvar/controlvar

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.