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

Đang mở
  • Có gì không ổn?
#1,543 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
15/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
analytics, api, backend, database

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
0
Fork
4
Merge trung bình
6 giờ 5 phút
Pull request đã merge (30 ngày)
453

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Controlvar/controlvar

Tất cả issue của Controlvar/controlvar

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.