Repository navigation
Fix 13F not reaching live algorithms - #19
Merged
AlexCatarino merged 5 commits intoOct 5, 2026
Merged
Conversation
JosueNina
changed the title
AlexCatarino
previously requested changes
Oct 5, 2026
AlexCatarino
requested changes
Oct 5, 2026
AlexCatarino
left a comment
AlexCatarino
left a comment
Member
There was a problem hiding this comment.
The fix looks right, and the sample zips carry the same rows shifted by a day. One blocking item, the history rebuild on PublishedOn, plus suggestions inline. I applied the FilingDate/EndTime suggestions locally, and the 179 13F tests still pass.
JosueNina
force-pushed
the
bug-sec13f-live-delivery
branch
from
October 5, 2026 16:33
6dde1f6 to
778f513
Compare
Live LEAN asks for the entry of today and never again for a past one. Entries were named after the filing date, and the job only publishes a day once EDGAR has listed it that night, so live always asked for an entry that did not exist yet and never for the one that did. A live algorithm received nothing. An entry is now named after the day it becomes available: the day after the EDGAR day a daily run reads, for every day that run reads, a day caught up late included. The rebuild names each filing's entry the day after it was filed. Time and EndTime come from the entry, so a backtest sees a filing when live can, and the filing date moves to its own FilingDate field. The sample output is shifted by a day, which is what the rebuild now writes.
LEAN opens the entry of a day in the zip of the ticker the security carries that day. With entries now named after the day they are published, a ticker taken on the filing date sent a row to a zip no one reads that entry from whenever the security was renamed in between, and to another company's zip when the ticker was reused. The CUSIP is still resolved on the filing date. Review follow-ups in the tests: the published history they seed uses the new layout, so the manager name tests exercise rows whose entry is not their filing date, and the clone and JSON round trip tests use a point whose Time differs from its FilingDate. A check that compared EndTime with the value the test passed in is removed.
A run publishes every row it reads under the day after its deployment date. A Manual Run with an old date would write an entry live has already gone by, with the rows visible to a backtest before the job had them, and a date typed in the future would hide them until that day. A run with today's date already catches up every missed day, so neither is needed. The same kind of guard as the forward universe files job, which refuses a date more than five days old.
No behavior changes. Several comments still said a row lands in the entry or the ticker file of its filing date, and the processor still gave the old 01:00 ET schedule as the reason for the timestamps. Processor - Say publication day where a comment said filing date for an entry or a ticker file - Replace the 01:00 ET schedule note with the rule the job now follows: run between the EDGAR index and midnight Also updates the README's map file row and a label in the pilot test.
From review. A point carried a second date: Time was the day before its entry and FilingDate the filing date. Keeping the filing date in Time and the entry in EndTime drops the second one, and a day caught up late still keeps its own filing date, with an EndTime of the day it was published. Data class - Keep Time as the filing date Parse reads off the line - Set EndTime from the entry date in the Reader, falling back to the day after Time when nothing sets it - Make FilingDate an alias of Time, and copy EndTime in Clone Also re-wraps a comment in SEC13FEdgarDay.
JosueNina
force-pushed
the
bug-sec13f-live-delivery
branch
from
October 5, 2026 16:36
778f513 to
a5f0df6
Compare
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
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.
A live algorithm never received 13F data. In live mode LEAN asks for today's entry and never again for a past one, and we named each entry after the filing date while the job only publishes it the next day, after EDGAR lists it. Live always asked for an entry that didn't exist yet. A paper live deployment got nothing for three days while backtests read the same files fine.
Each entry is now named after the day it becomes available, which is the day after the EDGAR day the run reads. A run that catches up a missed day publishes it under its own day too, so live still gets it and a backtest never sees it earlier than live could. Time stays the filing date, now also exposed as FilingDate, and EndTime comes from the entry. GetSource is unchanged.
I checked it with a local simulation that drives LEAN's own live reader with a manual clock against its backtest reader. It reproduces the failure on master, and with this change live and backtest get every day at the same time, including a day caught up late.
Things to act on