fix(scanner): key candidates.json by trading day, not calendar date (L4464 recovery)#257
Merged
Merged
Conversation
…L4464 recovery) The 2026-05-30 L4464 recovery failed at Research: the standalone Scanner wrote candidates/2026-05-30/ (calendar date, from the SF's date(Execution.StartTime)), but Research reads candidates/2026-05-29/ (its trading day, most_recent_trading_day(today)) — the same axis used by signals.json, sector_team_runs, and scanner_evaluations. The Phase-5 cutover's fail-loud (research #256) correctly caught the producer/consumer date-axis mismatch instead of silently producing nothing. Fix: scanner_handler normalizes run_date to the trading day via the alpha_engine_lib.trading_calendar chokepoint (on-or-before semantics: Sat/Sun/holiday → most recent trading day; trading day → unchanged). Now the Scanner and Research key off the identical date, and the write matches what ARTIFACT_REGISTRY already expects (scanner_candidates_json was flipped to the trading_day axis in config #356). Per DATE_CONVENTIONS — every trade artifact keys by trading day. Tests: test_run_date_normalized_to_trading_day (Sat→Fri, Sun→Fri, Fri→Fri) + existing happy/threading assertions updated. Suite 1672 → 1673. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
The 2026-05-30 recovery (post-#256) failed at Research — but the cutover's fail-loud worked exactly as designed, catching a real producer/consumer date-axis mismatch:
Everything else in the system keys trade artifacts by the trading day (
signals.json,sector_team_runs,scanner_evaluations, the Research run itself viamost_recent_trading_day(today)) — andARTIFACT_REGISTRYalready expectsscanner_candidates_jsonon the trading-day axis (config #356). The standalone Scanner was the lone calendar-keyed producer; it never mattered until the Phase-5 cutover made Research the first consumer.Fix
scanner_handlernormalizesrun_dateto the trading day via thealpha_engine_lib.trading_calendarchokepoint (on-or-before: Sat/Sun/holiday → most recent trading day; trading day → unchanged). Scanner and Research now key off the identical date.Tests
test_run_date_normalized_to_trading_day(Sat→Fri, Sun→Fri, Fri→Fri) + updated happy/threading assertions. Suite 1672 → 1673.Deploy / next
Scanner Lambda auto-rebuilds on merge (touches
lambda/). After merge + redeploy I'll re-run the scoped recovery (Scanner → Research → Backtester). Held for review.🤖 Generated with Claude Code