admin: recompute PR A's copied fact days from raw events before they expire
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- python
- Domain
- data-engineering
Research direction
Start with daily_facts.py and read _compute_day, facts_step, and sum_recent_facts, then review the assumptions in dependency #641. Work out which columns can be rebuilt from retained raw events and how to handle the 29-day history when processing oldest to newest. Done means the rebuild scope and treatment of unrebuildable fields are settled before a one-off recompute is attempted.
Written by the indexing model from the issue text.
Description
PR A's history copy (copy_daily_snapshot_history, #526) filled user_daily_facts from the legacy snapshot table with every metric column 0, operational state healthy / NULL code, tier unpaid, and data_quality='partial'. On prod those are the days 2026-07-29 → 2026-09-22. Complete facts start 2026-09-23.
After #641 the readers treat partial as unknown, so nothing publishes those zeros (e.g. /groups reports partial, not ready). But at 180 days the rows roll into analytics_daily_rollups (kept indefinitely) still partial, so that period stays unknown for good unless it is recomputed while its raw events exist. Raw events are kept 180 days (RAW_EVENT_RETENTION_DAYS), so the oldest copied day, 2026-07-29, becomes unrecoverable around 2027-01-25.
The daily job will not do it: its recompute sweep looks back only RECOMPUTE_LOOKBACK_DAYS = 6 (daily_facts.py:39).
Proposal: a one-off, throttled recompute of those days through _compute_day, run oldest → newest.
Things to settle first:
- Order matters.
facts_stepbuilds each day's segment from the prior 29 fact days (sum_recent_facts), so the first copied days have no real history behind them either. facts_stepreads currentuser_activity(list_activity(None)), and operational state and tier come from current configuration. Decide which columns a past-day recompute can honestly rebuild (event- and ledger-derived counts) and which staypartial.
Depends on #641.
- Dominant language
- Python
- Stars
- 767
- Forks
- 156
- Avg merge
- 21h 57m
- Merged PRs (30d)
- 92
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Open-Finance-Lab/AgenticTrading
-
fix(llm): a non-ASCII execution handoff raises UnicodeEncodeError instead of ExecutionHandoffErrorPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Open-Finance-Lab/AgenticTrading#659 ·
Maintainers usually reply within 1 day
-
fix(backtests): an LLM action with trailing whitespace ("buy ") is silently droppedPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Open-Finance-Lab/AgenticTrading#658 ·
Maintainers usually reply within 1 day
-
fix(llm): Gemini adapter drops thinking tokens from the output countPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Open-Finance-Lab/AgenticTrading#657 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Open-Finance-Lab/AgenticTrading#591 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Open-Finance-Lab/AgenticTrading#586 ·
Maintainers usually reply within 1 day
All issues in Open-Finance-Lab/AgenticTrading
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
MISP/misp-workbench#496 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
fossasia/visdom-dev#69 ·
Maintainers usually reply within 3 days
-
[Bug] Parameters named like a property break to_xcal()Possibly taken @atharvasalunke1267 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
collective/icalendar#2018 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day