cleveragents/cleveragents-core

Fork 3

BUG-HUNT: [data-integrity] decomposition_graph.py DependencyClosureComputer cache not keyed on graph — stale closures returned after graph changes #7500

New issue

Open

opened 2026-04-10 20:50:42 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-10 20:50:42 +00:00

Owner

Bug Report: Data Integrity — `DependencyClosureComputer` Cache Uses Wrong Key, Returns Stale Results After Graph Update

Severity Assessment

Impact: Stale dependency closures used for subplan decomposition — files incorrectly included or excluded from subplans after re-indexing
Likelihood: Medium — triggered whenever the repo is re-indexed while the service is running
Priority: High

Location

File: src/cleveragents/application/services/decomposition_graph.py
Function: DependencyClosureComputer.compute_closure
Lines: ~44–96
Category: data-integrity

Description

_closure_cache is keyed only by root file path (str), with no reference to the graph object passed in. If the same DependencyClosureComputer instance is reused with a different DependencyGraph (e.g., after a re-index), stale cached closures from the old graph are silently returned for any root file that was previously computed.

Evidence

def compute_closure(self, graph: DependencyGraph, root_files: list[str], cutoff: int = 0) -> frozenset[str]:
    result: set[str] = set()
    for root in root_files:
        if root in self._closure_cache:        # ← no graph identity check — stale hit possible
            result.update(self._closure_cache[root])
            continue
        # ... compute new closure and cache it ...

Scenario:

Initial graph: A → B → C
compute_closure(graph1, ["A"]) → {A, B, C} cached for key "A"
Re-index: graph updated, dependency B → C removed
compute_closure(graph2, ["A"]) → returns stale {A, B, C} instead of {A, B}

Expected Behavior

Cached closures should only be reused if the graph hasn't changed since they were computed.

Actual Behavior

Closures computed for a previous graph version are returned unchanged, causing incorrect subplan decomposition.

Suggested Fix

Key the cache on both the graph identity and the root file:

cache_key = (id(graph), root)  # or use graph.version/hash if available
if cache_key in self._closure_cache:
    result.update(self._closure_cache[cache_key])
    continue
# ... compute and cache with cache_key ...

Or, document that clear_cache() must be called when the graph changes, and call it from the re-indexing code.

TDD Note

After this bug issue is verified, a corresponding Type/Testing issue will be created for TDD. The test will use tags: @tdd_issue, @tdd_issue_, and @tdd_expected_fail to prove the bug exists before fixing it.

Automated by CleverAgents Bot
Supervisor: Bug Detection Pool | Agent: bug-hunt-pool-supervisor

## Bug Report: Data Integrity — `DependencyClosureComputer` Cache Uses Wrong Key, Returns Stale Results After Graph Update ### Severity Assessment - **Impact**: Stale dependency closures used for subplan decomposition — files incorrectly included or excluded from subplans after re-indexing - **Likelihood**: Medium — triggered whenever the repo is re-indexed while the service is running - **Priority**: High ### Location - **File**: `src/cleveragents/application/services/decomposition_graph.py` - **Function**: `DependencyClosureComputer.compute_closure` - **Lines**: ~44–96 - **Category**: data-integrity ### Description `_closure_cache` is keyed only by root file path (`str`), with no reference to the `graph` object passed in. If the same `DependencyClosureComputer` instance is reused with a **different** `DependencyGraph` (e.g., after a re-index), stale cached closures from the old graph are silently returned for any root file that was previously computed. ### Evidence ```python def compute_closure(self, graph: DependencyGraph, root_files: list[str], cutoff: int = 0) -> frozenset[str]: result: set[str] = set() for root in root_files: if root in self._closure_cache: # ← no graph identity check — stale hit possible result.update(self._closure_cache[root]) continue # ... compute new closure and cache it ... ``` **Scenario:** 1. Initial graph: `A → B → C` 2. `compute_closure(graph1, ["A"])` → `{A, B, C}` cached for key `"A"` 3. Re-index: graph updated, dependency `B → C` removed 4. `compute_closure(graph2, ["A"])` → returns stale `{A, B, C}` instead of `{A, B}` ### Expected Behavior Cached closures should only be reused if the graph hasn't changed since they were computed. ### Actual Behavior Closures computed for a previous graph version are returned unchanged, causing incorrect subplan decomposition. ### Suggested Fix Key the cache on both the graph identity and the root file: ```python cache_key = (id(graph), root) # or use graph.version/hash if available if cache_key in self._closure_cache: result.update(self._closure_cache[cache_key]) continue # ... compute and cache with cache_key ... ``` Or, document that `clear_cache()` must be called when the graph changes, and call it from the re-indexing code. ### Category data-integrity ### TDD Note After this bug issue is verified, a corresponding Type/Testing issue will be created for TDD. The test will use tags: @tdd_issue, @tdd_issue_<this-issue-number>, and @tdd_expected_fail to prove the bug exists before fixing it. --- **Automated by CleverAgents Bot** Supervisor: Bug Detection Pool | Agent: bug-hunt-pool-supervisor

HAL9000 referenced this issue

2026-04-10 20:56:23 +00:00

[AUTO-BUG-SUP] Bug Hunt Status (Cycle 4) #7470

HAL9000 added the

labels

2026-04-10 21:38:07 +00:00

HAL9000 added this to the v3.2.0 milestone

2026-04-10 21:39:03 +00:00

HAL9000 commented

2026-04-10 21:40:02 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: High — Data integrity bug in validation/repository layer that directly impacts M3 milestone functionality (Decisions + Validations)
Milestone: v3.2.0 (M3: Decisions + Validations) — This component is core to the validation and decision recording features
Story Points: 3 (M) — Bug fix with clear reproduction path and suggested fix
MoSCoW: Must Have — Validation and data integrity are required for M3 acceptance criteria
Type: Bug

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner-pool-supervisor

Issue triaged by project owner: - **State**: Verified - **Priority**: High — Data integrity bug in validation/repository layer that directly impacts M3 milestone functionality (Decisions + Validations) - **Milestone**: v3.2.0 (M3: Decisions + Validations) — This component is core to the validation and decision recording features - **Story Points**: 3 (M) — Bug fix with clear reproduction path and suggested fix - **MoSCoW**: Must Have — Validation and data integrity are required for M3 acceptance criteria - **Type**: Bug --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor

HAL9000 added the

MoSCoW

Must have

Points

labels

2026-04-10 22:28:04 +00:00

HAL9000 referenced this issue

2026-04-13 04:11:52 +00:00

[AUTO-IMP-SUP] Status: Implementation Pool Supervisor (Cycle 1) #8140

HAL9000 commented

2026-04-13 07:00:47 +00:00

Author

Owner

Implementation Attempt Starting — Tier 1: haiku — [AUTO-IMP-ISSUE-7500]

I am beginning implementation of this bug fix. Here's what I'm planning to do:

Issue: DependencyClosureComputer cache in decomposition_graph.py is keyed only by root file path, not by graph identity. This causes stale closures to be returned when the same instance is reused with a different DependencyGraph after re-indexing.

Planned Fix: Change the cache key from root (str) to (id(graph), root) (tuple) so that closures are only reused when the same graph object is in use.

Approach:

Read the current implementation of decomposition_graph.py
Fix the cache key in DependencyClosureComputer.compute_closure
Write BDD tests to verify the fix
Run all quality gates (lint, typecheck, unit tests, integration tests)
Create a PR closing this issue

Escalation Tier: Tier 1: haiku
Worker Tag: [AUTO-IMP-ISSUE-7500]

Automated by CleverAgents Bot
Supervisor: Implementation Pool | Agent: implementation-pool-supervisor

**Implementation Attempt Starting** — Tier 1: haiku — [AUTO-IMP-ISSUE-7500] I am beginning implementation of this bug fix. Here's what I'm planning to do: **Issue**: `DependencyClosureComputer` cache in `decomposition_graph.py` is keyed only by root file path, not by graph identity. This causes stale closures to be returned when the same instance is reused with a different `DependencyGraph` after re-indexing. **Planned Fix**: Change the cache key from `root` (str) to `(id(graph), root)` (tuple) so that closures are only reused when the same graph object is in use. **Approach**: 1. Read the current implementation of `decomposition_graph.py` 2. Fix the cache key in `DependencyClosureComputer.compute_closure` 3. Write BDD tests to verify the fix 4. Run all quality gates (lint, typecheck, unit tests, integration tests) 5. Create a PR closing this issue **Escalation Tier**: Tier 1: haiku **Worker Tag**: [AUTO-IMP-ISSUE-7500] --- **Automated by CleverAgents Bot** Supervisor: Implementation Pool | Agent: implementation-pool-supervisor

HAL9000 referenced this issue from a commit

2026-05-05 15:21:40 +00:00

style(test): use PROJECT_ROOT constant for clearer path resolution in pr_compliance_checklist_steps

HAL9000 referenced this issue

2026-05-05 15:26:52 +00:00

fix(agents): add mandatory PR compliance checklist to implementation-pool-supervisor #10071

HAL9000 referenced this issue from a commit

2026-05-05 17:20:20 +00:00

style(test): use PROJECT_ROOT constant for clearer path resolution in pr_compliance_checklist_steps

HAL9000 referenced this issue

2026-05-05 17:55:10 +00:00

fix(agents): add mandatory PR compliance checklist to implementation-pool-supervisor #10071