Tracking: a retried event is stored twice, so revenue and count metrics double-count it
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 15/100
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.idis generated by the server;- the
eventstable 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.valueper 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
/assignis 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.
- 主要语言
- Python
- 星标
- 0
- 派生
- 4
- 平均合并
- 6 小时 43 分钟
- 30 天内合并 PR
- 414
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Controlvar/controlvar 的其他 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 82/100
Controlvar/controlvar#1813 ·
维护者通常 1 天内回复
-
bug
难度 1/5 1-3 小时 新手友好度 88/100
Controlvar/controlvar#1806 ·
维护者通常 1 天内回复
-
Dashboard: an archived flag shows Off with an on/off switch the API refuses可能已有人在做 @amarkanday 于 1 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 72/100
Controlvar/controlvar#1748 · 1 条评论 ·
维护者通常 1 天内回复
-
Dashboard: the sequential panel's "Ready to stop" banner shows no sample-ratio-mismatch caution可能已有人在做 @amarkanday 于 1 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 68/100
Controlvar/controlvar#1737 · 1 条评论 ·
维护者通常 1 天内回复
-
dashboard: a split URL draft's variant edit shows generic copy when the API refuses it可能已有人在做 @amarkanday 于 1 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 70/100
Controlvar/controlvar#1562 · 1 条评论 ·
维护者通常 1 天内回复
查看 Controlvar/controlvar 的全部 Issue
相似的 Issue
-
integration: logger
难度 2/5 1-3 小时 新手友好度 68/100
home-assistant/core#191147 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
documentation p4
难度 1/5 1-3 小时 新手友好度 88/100
MillenniumDawn/focus-tree-creation-tool#417 ·
维护者通常 3 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
CharlesP44/Beem_Energy#96 ·
-
难度 2/5 1-3 小时 新手友好度 88/100
rheeloaded/paperpull#153 ·
维护者通常 1 天内回复