Always regenerate projects index so variant-flag toggles refresh links#168
Conversation
The projects index was gated on a `any_cache_updated` flag that only flipped when source JSONL files changed. Toggling a variant flag like `--compact` / `--no-timestamps` / `--detail` between runs produces new per-project output filenames (e.g. `combined_transcripts.compact.md`) but doesn't touch the cache — so the index kept linking to the previous run's filenames. The same bug bit `--expand-paths --combined no` (per-session bullet links) and the symmetric toggle-back case. Switching to unconditional regeneration: the index is built from `project_summaries` already in memory (one template pass + one file write over already-aggregated data), so the saved work on a true no-op run is negligible compared to the per-project cache check that already ran. Drops the `any_cache_updated` flag, the `renderer.is_outdated(index_path)` call, and the "Index ... is current, skipping regeneration" / "Index regenerated" log lines that are no longer informative. Regression tests in `test_output_paths.py::TestProjectsIndexVariantRefresh` cover the three scenarios: - forward toggle (default → `--compact`), - `--expand-paths --combined no` + `--compact`, - backward toggle (`--compact` → default, file already on disk). Existing `test_projects_index_regeneration_on_jsonl_change` updated to pin the new always-regenerate contract (mtime advances on no-op re-runs) and assert the removed log line stays gone.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughIndex generation is refactored to always run unconditionally, removing cache-update tracking that previously gated regeneration. Tests confirm the index rewrites on every run and that links refresh when output format variants toggle across consecutive invocations. ChangesUnconditional Index Regeneration
Variant Refresh Regression Tests
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
test/test_html_regeneration.py (1)
133-202: 💤 Low valueTest correctly validates always-regenerate contract.
The switch to
st_mtime_nsfor nanosecond precision is more reliable for timing assertions, and the test properly verifies both the no-op always-regen behavior and regeneration after JSONL changes.Optional enhancement: verify content changes
The test could strengthen the third-run validation by confirming the new JSONL content actually appears in the regenerated index:
post_change_mtime_ns = index_file.stat().st_mtime_ns process_projects_hierarchy(projects_dir) assert index_file.stat().st_mtime_ns > post_change_mtime_ns +# Verify the new content appears in the index +new_content = index_file.read_text(encoding="utf-8") +assert "updated content for index regeneration test" in new_contentThis would fully validate the docstring's claim that "JSONL edits are picked up."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/test_html_regeneration.py` around lines 133 - 202, The test verifies always-regenerate and JSONL-change detection but doesn't assert that the new JSONL line actually appears in the regenerated index; after calling process_projects_hierarchy(projects_dir) in the third run, read index_file (from variable index_file) and assert the new_message (or a distinctive substring like the summary text) is present to prove the content was incorporated; update test_projects_index_regeneration_on_jsonl_change to open and read index_file.read_text(encoding="utf-8") after the final process_projects_hierarchy call and assert the expected JSON snippet or summary string is in the content.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@test/test_html_regeneration.py`:
- Around line 133-202: The test verifies always-regenerate and JSONL-change
detection but doesn't assert that the new JSONL line actually appears in the
regenerated index; after calling process_projects_hierarchy(projects_dir) in the
third run, read index_file (from variable index_file) and assert the new_message
(or a distinctive substring like the summary text) is present to prove the
content was incorporated; update
test_projects_index_regeneration_on_jsonl_change to open and read
index_file.read_text(encoding="utf-8") after the final
process_projects_hierarchy call and assert the expected JSON snippet or summary
string is in the content.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e8a9e2d5-67af-4a36-9ce1-257022597d91
📒 Files selected for processing (3)
claude_code_log/converter.pytest/test_html_regeneration.pytest/test_output_paths.py
Two cleanups on top of b682db2: 1. `test/test_html_regeneration.py::test_projects_index_regeneration_on_jsonl_change`: CR suggested asserting that the appended JSONL content appears in the regenerated index. The projects index surfaces project-level metadata (counts, date ranges, session AI titles) — not raw message text — so a string match on the appended message body isn't a reliable signal. Replaced with a direct before/after content comparison: catches the same "byte-equivalent rewrite" stale bug an mtime check alone would miss, without depending on internal template choices about which JSONL fields surface where. 2. `test/test_integration_realistic.py::test_index_regenerated_when_project_cache_updates`: Docstring rewritten — pre-PR-168 the test pinned "index regenerates when project cache changes", but with always-regenerate semantics the JSONL edit is now incidental cargo. New docstring describes what the assertion actually pins today (mtime advances on every call) and notes the JSONL edit's historical purpose.
Summary
any_cache_updatedgate on projects-index regeneration and the now-unusedrenderer.is_outdated(index_path)check.project_summariesaggregation (one template pass + one file write).Why
The previous gate only fired when source JSONL files changed. Toggling a variant flag like
--compact/--no-timestamps/--detailbetween runs produces new per-project filenames (e.g.combined_transcripts.compact.md) but doesn't touch the cache, so the index kept linking to the previous run's filenames. The bug also bit--expand-paths --combined no(per-session bullet links) and the symmetric toggle-back case (going back to the bare variant when the file already exists on disk).A first attempt tracked output writes via a new
any_output_writtenflag — that fixed the forward toggle but left the backward toggle stale. Always regenerating closes both directions and dispenses with the per-call freshness logic; the saved work on a true no-op run is negligible vs the per-project cache work that already ran.Test plan
test/test_output_paths.py::TestProjectsIndexVariantRefresh— three new regression scenarios:--compact)--expand-paths --combined no+--compact--compact→ default, file already on disk)test/test_html_regeneration.py::test_projects_index_regeneration_on_jsonl_change— updated to pin the always-regenerate contract and assert the removed "skipping regeneration" log line stays gone.just ciclean (1791 unit + benchmark; ruff / pyright / ty all green).Summary by CodeRabbit
Bug Fixes
Tests