feat(lore-0167): complete — usd_rate live on prod, constraint 5 passed, coverage start corrected - #194
Merged
Conversation
…~2025-09 Measured on prod right after the first snapshot: oracle_prices holds 87,030 peg rows under oracle_name='reflector', oldest 2026-03-11 14:00:00. 43,514 per asset over 152 days is 99.4% of a continuous 5-minute cadence, so the worker began in March 2026. The ~2025-09 figure was never verified. It had propagated into six files - 0167, 0168, 0154, 0131, 0088 and the schema overview - and was the headline reason 0167 jumped the queue. The real expiry is the 202603 partition ageing out at ~2027-04, about six months later than argued. On the corrected numbers 0172 - live wrong data feeding TVL on 102 pools - should have gone first. The work here is correct and unblocks 0168, so nothing is wasted, but the sequencing rested on a number nobody had checked. The copy itself has no gap: oracle_name was the one plausible way older readings could have been missed, since the event-decoded path also writes oracle rows. Measured, reflector is the only name present for peg assets, so the 87,028 copied rows are everything that exists. Also records the deploy outcome: the 0141 stale-asset trap was live (the on-disk bootstrap was 17 days old with zero usd_rate references) and was caught only by checking the artifact before deploying.
…referenced The previous commit fixed the ~2025-09 dates across six files but its script aborted before writing 0167's explanatory section, leaving a dangling reference to a section that did not exist. Records what was measured (oracle_prices peg coverage starts 2026-03-11, not ~2025-09), the consequence (real expiry ~2027-04, six months later than argued, so 0172 should have been sequenced first), the confirmation that the copy has no gap (reflector is the only oracle_name present for peg assets), and the deploy outcome including the live 0141 stale-artifact near-miss.
…ing on 0116 0154 constraint 5 - the gate before anything prices off usd_rate - PASSED on prod over 103,016 USDC-quoted daily candles. 9,022 oracle-tier candles reproduce exactly from the stored rate, which is the question the check asks. 93,849 sit in the expected flat-$1 peg band, incidentally quantifying what 0168 is worth. The 145 outliers (0.14%) were chased rather than waved through. They are a Decimal(38,14) representable-floor artifact: close sits at single-digit multiples of 1e-14 and every candle loses exactly one ulp (8->7, 10->9, 11->10, 15->14) through a float round-trip, not a rounding rule. Relative error reaches 14.25%, absolute error is 1e-14 per unit. The same error appears against any rate including enrichment's own, so it is not a rate defect. Recorded on 0116 as the mirror image of that task's absurdly-large close_usd - same root (price outside Decimal(38,14)'s usable range), opposite end - with the warning that a relative-error tolerance over these assets will always look alarming while the absolute error is negligible. Two ACs stay [~] deliberately: the ASOF rule is documented at the table but implemented by its first consumer (0168), and pre-oracle absence is now verified on real data rather than argued from construction. Shipped: prices.usd_rate live on ch-prod-01, oracle-worker deployed and populating, 87,028 rows at method='oracle', averages 1.000271 / 0.99959. 0168 is now a one-expression change.
karczuRF
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
0167 is deployed and populated on prod — and verifying it disproved a number this task had been using as its main argument.
The population worked
methodoracleThe 0141 stale-asset trap was live:
target/lambda/oracle-worker/bootstrapwas 17 days old with zerousd_ratereferences. Caught only by checking the artifact before deploying. After rebuild, LambdaLastModifiedlanded 3 minutes after the local build.The correction
Coverage starts 2026-03-11, not
~2025-09. 43,514 rows per asset over 152 days is 99.4% of a continuous 5-minute cadence, so the worker began in March 2026. The earlier figure was never verified.It had propagated into six files — 0167, 0168, 0154, 0131, 0088 and the schema overview — all corrected here.
What that changes
202603ageing out at ~2027-04, not ~2026-10/11 — about six months later than argued.oracle_namewas the one plausible way older readings could have been missed, since the event-decoded path also writes oracle rows. Measured,reflectoris the only name present for peg assets — the 87,028 copied rows are everything that exists.Lesson
The
~2025-09figure travelled through six files and became the basis for a scheduling decision without anyone runningSELECT min(timestamp). It cost one query, and was caught only because the populated table'soldestcolumn disagreed with the task text.