daaain / daaain/claude-code-log

Per-project staleness check in process_projects_hierarchy doesn't gate on requested outputs

Open
#274 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Python
Stars
1.2k
Forks
98
Avg merge
3d 2h
Merged PRs (30d)
13

Description

From https://github.com/daaain/claude-code-log/pull/272#discussion_r3567034406

Root cause

In claude_code_log/converter.py, the staleness check that decides whether a project needs (re)conversion doesn't distinguish which artifacts were actually requested (write_combined, generate_individual_sessions, use_cache). Today (in _plan_project, and previously in the inline loop it was extracted from):

if write_combined:
    needs_work = (
        bool(modified_files)
        or bool(stale_sessions)
        or combined_stale
        or not output_path.exists()
    )
else:
    needs_work = bool(modified_files) or bool(stale_sessions)

Affected scenarios

  1. use_cache=False + write_combined=False (individual-session-only, no cache): cache_manager is None, so modified_files and stale_sessions are always [] (the ternaries fall through to the else branch). needs_work ends up False unconditionally, so no per-session files are ever generated, yet the index still links to session-{id}... paths that were never written — producing 404 links.
  2. Combined-only runs (generate_individual_sessions=False, write_combined=True): stale_sessions is still computed and can force needs_work=True (or keep it True) even though individual files aren't being produced and their staleness is irrelevant to what's requested — causing unnecessary reconversion every run.
  3. Individual-only runs (generate_individual_sessions=True, write_combined=False): symmetric case — combined_stale/output_path.exists() are correctly skipped, but this branch was only reachable via write_combined, not generate_individual_sessions, so there's no explicit signal tying the check to what was requested; it currently happens to work only because write_combined=False is the only lever, conflating "don't check combined staleness" with "combined wasn't requested."

Proposed fix outline

  • Thread generate_individual_sessions into _plan_project (and its caller in process_projects_hierarchy).
  • Gate stale_sessions/modified_files evaluation by generate_individual_sessions, and combined_stale/output_path.exists() by write_combined.
  • When cache_manager is None (i.e., use_cache=False), don't rely on empty modified_files/stale_sessions lists as "nothing to do" — treat any requested output as needing work whenever there's no cache to have already produced it.
  • Add regression tests for: (a) use_cache=False, write_combined=False, generate_individual_sessions=True, (b) write_combined=True, generate_individual_sessions=False steady-state (no unnecessary reconversion), (c) write_combined=False, generate_individual_sessions=True steady-state.

Files/areas

  • claude_code_log/converter.py: _plan_project, its call site in process_projects_hierarchy (Phase 1 planning loop).
  • test/test_parallel_processing.py or a new staleness-focused test module for the new coverage.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read claude_code_log/converter.py at _plan_project and its Phase 1 call site in process_projects_hierarchy. Then run the relevant tests in test/test_parallel_processing.py, adding coverage for the three listed cache and output combinations. Done means requested individual outputs are generated without a cache, and steady-state runs do not reconvert outputs that were not requested.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
74/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.