Todayedited3 min read
ALLI-29130 — only read the current feed file
PR 702 · Jira · interactive simulator
Uploading a feed again on the same day creates a second physical file below the same snapshot_date. The old Athena query narrowed the scan to the day, but feed_file is an object-key segment rather than a Glue partition, so both the 9:00 AM and 10:00 AM copies matched. That could duplicate products, bring back a product removed by the later upload, or let an older row win during rendering. The linked Viator incident showed unusually large creative totals of 205,423 and 837,893, which is consistent with that multiplication.
PR 702 keeps the date filter for fast partition pruning, then uses Athena's hidden file-path column ($path) to select the exact S3 object chosen for the run. Rendering, cleanup, and explicit historical comparisons all share that query path. The regression creates two files one hour apart on the same calendar day, verifies the query contains the current file's exact path, and verifies the older file ID is absent.
Tested: 2,140 tests and 82 subtests pass; repo-wide code quality checks and formatting checks pass.
flowchart LR
A["9:00 AM upload<br/>feed_file=A"] --> D["Same storage date<br/>snapshot_date=20260908"]
B["10:00 AM resync<br/>feed_file=B becomes current"] --> D
subgraph OLD["Before PR 702"]
D --> O1["Query filters by date"]
O1 --> O2["Athena reads A + B"]
O2 --> O3["VTR-101 appears twice<br/>removed VTR-102 returns"]
end
subgraph NEW["After PR 702"]
D --> N1["Keep date filter for speed"]
N1 --> N2["Exact $path selects feed_file=B"]
N2 --> N3["Only current rows<br/>VTR-101 at $79 + VTR-103"]
end
classDef bad fill:#ffd7d5,color:#24292f,stroke:#cf222e;
classDef good fill:#d3f5db,color:#24292f,stroke:#1a7f37;
classDef ctx fill:#eaeef2,color:#24292f,stroke:#57606a;
class A,B,D ctx;
class O1,O2,O3 bad;
class N1,N2,N3 good;
The date filter narrows Athena to the right day; the exact path makes sure only the selected upload reaches the run.
Follow-up — why the PR file links opened “nothing to compare”
The original Markdown used repository-relative targets such as
project/studio/services/athena_service.py. Because a newly opened PR lives under GitHub's/compare/...route, the browser combined those paths and treatedproject/studio/services/athena_service.pyas a branch to compare. That produced the empty “There isn't anything to compare” page.Both links on PR 702 now use immutable absolute URLs at commit
105e32d2: the production change opens directly at lines 199–210, and the same-day regression opens at lines 78–102.flowchart LR A["PR page<br/>/compare/branch"] --> B["Relative target<br/>project/studio/..."] B --> C["Wrong result<br/>/compare/project/studio/..."] A --> D["Absolute target<br/>/blob/105e32d2/..."] D --> E["Correct file<br/>lines 199–210"] classDef bad fill:#ffd7d5,color:#24292f,stroke:#cf222e; classDef good fill:#d3f5db,color:#24292f,stroke:#1a7f37; classDef ctx fill:#eaeef2,color:#24292f,stroke:#57606a; class A,B ctx; class C bad; class D,E good;Follow-up — what local tests prove vs. what still needs staging
PR 702 has not yet been exercised against real staging Athena. The local suite mocks the Athena client, so its 2,140 tests and 82 subtests prove that the application builds the intended query—including the exact for the selected feed file—and that existing behavior remains intact. It cannot prove that staging Athena accepts the hidden path column against the deployed Glue table and real S3 layout.