cleveragents/cleveragents-core

Fork 3

UAT: `InMemoryGraphIndexBackend.query()` ignores SPARQL string entirely — returns all triples regardless of query filter #5864

New issue

Open

opened 2026-04-09 11:04:36 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-09 11:04:36 +00:00

Owner

Bug Report

What Was Tested

InMemoryGraphIndexBackend.query() in src/cleveragents/domain/models/acms/index_stubs.py — the stub graph backend used as the default in the DI container.

Expected Behavior (from spec)

Per docs/specification.md §45519 and the GraphIndexBackend protocol (src/cleveragents/domain/models/acms/index_backends.py, lines 289–314):

Execute a SPARQL query against the graph. [...] Implementations must parameterise or sanitise the sparql argument before passing it to the underlying store.

The query() method should execute the SPARQL query and return only the bindings that match the query's WHERE clause.

Actual Behavior

The InMemoryGraphIndexBackend.query() implementation (lines 266–271) completely ignores the SPARQL string and returns ALL triples for the project as binding dicts:

def query(self, project: str, sparql: str) -> list[dict[str, str]]:
    """Return all triples for *project* as binding dicts (stub)."""
    _require_non_empty(project, "project")
    _require_non_empty(sparql, "sparql")
    triples = self._triples.get(project, [])
    return [{"s": s, "p": p, "o": o} for s, p, o in triples]

This means:

SELECT ?s ?o WHERE { ?s uko:layer "2" } returns ALL triples, not just layer-2 triples
SELECT ?s ?p ?o WHERE { ?s uko:sourceResource <uko://resource/X> } returns ALL triples, not just triples for resource X
Any SPARQL-based filtering in UKOQueryInterface is silently broken

This is the default graph backend wired in the DI container (application/container.py, line 839: index_graph_backend = providers.Singleton(InMemoryGraphIndexBackend)), so all UKO graph queries in the default configuration are non-functional.

Impact

UKOQueryInterface.classify_resource() returns incorrect results — it processes all triples for the project instead of only triples for the queried resource
UKOQueryInterface.get_resources_by_layer() returns incorrect results
UKOGraphPersistence.save() works correctly (uses SELECT ?s ?p ?o WHERE { ?s ?p ?o } which happens to match all triples)
Any future SPARQL-based context strategy will silently return wrong results

Note on Scope

Issue #872 tracks implementing a real graph backend (Blazegraph/Neo4j). This issue specifically tracks the stub's incorrect behavior — the stub should at minimum implement basic SPARQL pattern matching for the predicates used by UKOQueryInterface, or clearly document that it does not support SPARQL filtering and callers must not rely on it for filtered queries.

Code Location

src/cleveragents/domain/models/acms/index_stubs.py, lines 266–271 (InMemoryGraphIndexBackend.query)

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Bug Report ### What Was Tested `InMemoryGraphIndexBackend.query()` in `src/cleveragents/domain/models/acms/index_stubs.py` — the stub graph backend used as the default in the DI container. ### Expected Behavior (from spec) Per `docs/specification.md` §45519 and the `GraphIndexBackend` protocol (`src/cleveragents/domain/models/acms/index_backends.py`, lines 289–314): > Execute a SPARQL query against the graph. [...] Implementations **must** parameterise or sanitise the *sparql* argument before passing it to the underlying store. The `query()` method should execute the SPARQL query and return only the bindings that match the query's WHERE clause. ### Actual Behavior The `InMemoryGraphIndexBackend.query()` implementation (lines 266–271) **completely ignores the SPARQL string** and returns ALL triples for the project as binding dicts: ```python def query(self, project: str, sparql: str) -> list[dict[str, str]]: """Return all triples for *project* as binding dicts (stub).""" _require_non_empty(project, "project") _require_non_empty(sparql, "sparql") triples = self._triples.get(project, []) return [{"s": s, "p": p, "o": o} for s, p, o in triples] ``` This means: 1. `SELECT ?s ?o WHERE { ?s uko:layer "2" }` returns ALL triples, not just layer-2 triples 2. `SELECT ?s ?p ?o WHERE { ?s uko:sourceResource <uko://resource/X> }` returns ALL triples, not just triples for resource X 3. Any SPARQL-based filtering in `UKOQueryInterface` is silently broken This is the **default graph backend** wired in the DI container (`application/container.py`, line 839: `index_graph_backend = providers.Singleton(InMemoryGraphIndexBackend)`), so all UKO graph queries in the default configuration are non-functional. ### Impact - `UKOQueryInterface.classify_resource()` returns incorrect results — it processes all triples for the project instead of only triples for the queried resource - `UKOQueryInterface.get_resources_by_layer()` returns incorrect results - `UKOGraphPersistence.save()` works correctly (uses `SELECT ?s ?p ?o WHERE { ?s ?p ?o }` which happens to match all triples) - Any future SPARQL-based context strategy will silently return wrong results ### Note on Scope Issue #872 tracks implementing a real graph backend (Blazegraph/Neo4j). This issue specifically tracks the stub's incorrect behavior — the stub should at minimum implement basic SPARQL pattern matching for the predicates used by `UKOQueryInterface`, or clearly document that it does not support SPARQL filtering and callers must not rely on it for filtered queries. ### Code Location - `src/cleveragents/domain/models/acms/index_stubs.py`, lines 266–271 (`InMemoryGraphIndexBackend.query`) --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 11:07:58 +00:00

HAL9000 referenced this issue

2026-04-09 11:23:28 +00:00

[AUTO-WATCHDOG] System Health Report (Cycle 13) #5754

HAL9000 added the

Points

MoSCoW

Must have

labels

2026-04-09 11:30:45 +00:00

HAL9000 added this to the v3.4.0 milestone

2026-04-09 11:37:11 +00:00

HAL9000 commented

2026-04-09 11:38:30 +00:00

Author

Owner

MoSCoW classification: Must Have

Rationale: This is a Priority/Critical bug — InMemoryGraphIndexBackend.query() ignores SPARQL strings entirely and returns empty results. The ACMS (Advanced Context Management System) relies on graph index queries for context assembly. A backend that silently ignores queries and returns empty results would make the entire graph index feature non-functional. This is a core component per the specification's context management architecture.

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

MoSCoW classification: **Must Have** Rationale: This is a `Priority/Critical` bug — `InMemoryGraphIndexBackend.query()` ignores SPARQL strings entirely and returns empty results. The ACMS (Advanced Context Management System) relies on graph index queries for context assembly. A backend that silently ignores queries and returns empty results would make the entire graph index feature non-functional. This is a core component per the specification's context management architecture. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 added

and removed

labels

2026-04-09 11:40:04 +00:00

HAL9000 commented

2026-04-09 11:40:23 +00:00

Author

Owner

Label compliance fix applied:

Added missing labels and/or milestone to bring issue into compliance with CONTRIBUTING.md

Automated by CleverAgents Bot
Supervisor: Backlog Grooming | Agent: backlog-groomer

Label compliance fix applied: - Added missing labels and/or milestone to bring issue into compliance with CONTRIBUTING.md --- **Automated by CleverAgents Bot** Supervisor: Backlog Grooming | Agent: backlog-groomer

HAL9000 referenced this issue

2026-04-09 11:45:00 +00:00

[AUTO-WATCHDOG] System Health Report (Cycle 21) #5915

HAL9000 added

and removed

labels

2026-04-09 11:47:35 +00:00

HAL9000 referenced this issue