INTERACTIVE DEMO — SYNTHETIC DATA
Master File Report Pipeline
A merge function whose docstring described a per-order upsert, and which does a date-overlap replace. Both policies run here, over the same two frames, so you can see the row they disagree about.
Every record on this page is fabricated. No production system, customer, employee or credential is involved.
The production system behind this demo was engineered by Prada Dipa — LinkedIn profile, opens in a new tab and Luthfi Aditya — LinkedIn profile, opens in a new tab. I managed and directed it — requirements, technical review, QA and rollout.
The merge, running in your browser
Pick a policy and a window. The third frame is what the orders tab would hold afterwards.
WHERE THE TWO POLICIES DISAGREE
One row. Everything else is identical under both policies.
deleted by the date-overlap replace, kept by the upsert — it is inside the window and the pull did not return it.
9
1
2
1
0
0
ORDERS TAB, BEFORE
- MER-0998$268
- MER-0999$742
- MER-1001$149
IN WINDOW
- MER-1002$402
IN WINDOW
- MER-1003$516
IN WINDOW
- MER-1004$288
IN WINDOW
- MER-1005$655
IN WINDOW
- MER-1006$131
IN WINDOW
NEW PULL
- MER-1001$149
- MER-1002$361
- MER-1003$516
- MER-1005$655
- MER-1006$131
- MER-1007$294
- MER-1008$1,032
ORDERS TAB, AFTER
- MER-0998$268
- MER-0999$742
- MER-1001$149
- MER-1002$361
UPDATED
- MER-1003$516
- MER-1005$655
- MER-1006$131
- MER-1007$294
ADDED
- MER-1008$1,032
ADDED
- MER-1004$288
DELETED
The merge is a date-overlap replace, and its docstring says upsert
CONTEXT
DECISION
CONSEQUENCES
- An order genuinely removed upstream disappears from the tab, which is usually what was wanted and is the reason nobody noticed.
- An order the pull merely failed to return — cancelled, or excluded by a status filter — also disappears. That is MER-1004 above.
- Correctness depends on the declared window and the pull agreeing about their edges. Where they drift, the same order is written twice.
WHY THIS IS ON THE PAGE AT ALL
Restated in my own words. The original records are in a private repository and name internal systems; nothing quoted from them appears here, and neither do any of their examples.
The refresh mutates the shared header dictionary in place
The storefront token is short-lived and a full run outlives it. Several modules import the header dictionary once, at import time. So the refresh has to update the object those modules are already holding — not rebind a name.
WHAT IT DOES
def refresh(headers):
token = exchange_client_credentials()
# mutate the object every importer
# is already holding a reference to
headers["X-Access-Token"] = tokenEvery module that imported HEADERS from the auth module sees the new token immediately. No restart, no re-import, no plumbing a token through forty call sites.
THE TIDY-UP THAT BREAKS IT
def refresh():
global HEADERS
# rebinds the name in THIS module
HEADERS = {
"X-Access-Token":
exchange_client_credentials()
}Importers bound their own name to the old dictionary at import time. Rebinding the module global leaves them pointing at it, still sending an expired token — and only after the token's lifetime, part-way through a long run.
It is worth a record because the correctness lives in a property of Python’s import system rather than in anything visible at the call site, and because the version that breaks it looks tidier.
There is no interactive version of this, deliberately. Demonstrating it would mean reproducing module-level name binding in a browser, and the visitor would be watching my imitation of Python rather than the thing itself. A widget that convincing about a claim it cannot support is worse than a paragraph.