fix(seed): shipping TTL 1h to 8h to survive the 6h cron cadence#2955
Conversation
SHIPPING_TTL was 3600 (1 hour) while the cron interval is 6 hours (api/health.js shippingRates maxStaleMin=420 = 6h + 1h grace). The key was expiring 5 hours before every next run, producing permanent gaps in downstream consumers that read supply_chain:shipping:v2. Observed failure: derived-signals seed bundle cross-source-signals seeder reported supply_chain:shipping:v2 missing in production, producing 0 composite escalation zones. A prior PR in this file bumped TARIFF_TTL to 28800 (8h) and CUSTOMS_TTL to 86400 (24h) with the explicit "2h buffer over 6h cron cadence (was TRADE_TTL=6h = 0 buffer)" rationale in a comment, but missed SHIPPING_TTL which has been at 1h since the original commit. This brings shipping in line with the same pattern.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThis PR fixes a production gap in Confidence Score: 5/5Safe to merge — single-constant fix with no logic changes, directly confirmed by health.js config and sibling TTL comments. The change is a single integer constant bump backed by clear evidence (health.js maxStaleMin=420, production failure log, sibling TARIFF_TTL comment). Only P2 finding is a pre-existing TRADE_TTL zero-buffer issue unrelated to this PR. No files require special attention. Important Files Changed
Sequence DiagramsequenceDiagram
participant Cron as Railway Cron (every 6h)
participant Seed as seed-supply-chain-trade.mjs
participant Redis as Redis (Upstash)
participant DS as cross-source-signals
Cron->>Seed: trigger
Seed->>Redis: SET supply_chain:shipping:v2 EX 28800 (8h)
Note over Redis: Key alive for 8h
Seed->>Redis: SET seed-meta:supply_chain:shipping EX 604800 (7d)
Note over Cron,Redis: 6h later — next cron run
Cron->>Seed: trigger
DS->>Redis: GET supply_chain:shipping:v2
Note over DS,Redis: Key still alive (8h TTL not expired)\nwas: key expired at 1h → gap for 5h
Seed->>Redis: SET supply_chain:shipping:v2 EX 28800 (refresh)
Reviews (1): Last reviewed commit: "fix(seed): shipping TTL 1h to 8h to surv..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| const SHIPPING_TTL = 3600; | ||
| const SHIPPING_TTL = 28800; // 8h — 2h buffer over 6h cron cadence (was 1h = 5h expired gap) | ||
| const TRADE_TTL = 21600; |
There was a problem hiding this comment.
TRADE_TTL still has zero cron buffer
TRADE_TTL = 21600 is exactly equal to the 6 h cron cadence. Keys written with this TTL (trade:barriers, trade:restrictions, and flow keys on lines 671–673) expire at the same instant the next cron run is supposed to start — any delay or missed run causes the same gap that SHIPPING_TTL just fixed. The sibling comment on TARIFF_TTL already documents the risk ("was TRADE_TTL=6h = 0 buffer"). Consider bumping TRADE_TTL to 28800 (8 h) as a follow-up.
| const TRADE_TTL = 21600; | |
| const TRADE_TTL = 28800; // 8h — 2h buffer over 6h cron cadence (was 6h = 0 buffer) |
There was a problem hiding this comment.
Fixed in 3b16fb2. Bumped TRADE_TTL to 28800 (8h) to match SHIPPING_TTL/TARIFF_TTL pattern.
TRADE_TTL was exactly equal to the 6h Railway cron cadence, so trade:barriers, trade:restrictions, and every trade:flows:* key expired at the instant the next cron run was supposed to start. Any cron delay or skipped run = silent gap in downstream consumers (same failure mode as SHIPPING_TTL, fixed in this PR). The sibling TARIFF_TTL comment already documented the risk. Bump to 8h (2h buffer) to match SHIPPING_TTL/TARIFF_TTL pattern. None of the TRADE_TTL-backed keys are registered in api/health.js so staleness would have gone unnoticed until a panel lost data.
1 participant
Summary
SHIPPING_TTLwas3600(1 hour) while the cron cadence is 6 hours. Thesupply_chain:shipping:v2key was expiring 5 hours before every next run, producing permanent gaps in downstream consumers (cross-source-signals, forecasts, etc).Evidence
api/health.js:193hasshippingRates: { maxStaleMin: 420 }= 6h + 1h gracescripts/seed-supply-chain-trade.mjs) already has the pattern for its sibling TTLs:TARIFF_TTL = 28800; // 8h — 2h buffer over 6h cron cadence (was TRADE_TTL=6h = 0 buffer)CUSTOMS_TTL = 86400; // 24h — monthly Treasury data, matches maxStaleMin:1440SHIPPING_TTLwas left at 1h when the other TTLs were bumped.supply_chain:shipping:v2missing, producing 0 composite escalation zones.Fix
Bump
SHIPPING_TTLto28800(8h) to match the sibling TTLs and the documented "2h buffer over 6h cron cadence" pattern.Test plan
Found 20/23 source keys populated(up from 19/23)intelligence:cross-source-signals:v1detects more than 0 composite escalation zones when appropriate