Source: Source pull request number: 341 in rohitg00/agentmemory (URL omitted to avoid GitHub cross-reference)
Title: fix(graph): report trigger failures separately
Author: wyh0626
State: open
Draft: no
Merged: no
Head: wyh0626/agentmemory:codex/fix-graph-trigger-errors @ 177bd09
Base: main @ 1c8713f
Labels: (none)
Changed files: 0
Commits: 0
Created: 2026-05-13T15:57:13Z
Updated: 2026-05-17T09:42:42Z
Closed: (not closed)
Merged at: (not merged)
Original PR body:
Summary
Refs #338.
The graph REST endpoints were treating every graph trigger failure as if graph extraction was disabled. That made a real backend error, for example iii::engine Function not found: mem::graph-stats, show up as 503 Knowledge graph not enabled.
This keeps the disabled-flag response, but only uses it when GRAPH_EXTRACTION_ENABLED is actually off. If the flag is on and the underlying graph function fails, the REST endpoint now returns a 500 with the function id and the original error message. That should make reports like #338 much easier to diagnose.
I also added a startup log when graph extraction is off. The log calls out that GRAPH_EXTRACTION_ENABLED=true has to be set in the process running agentmemory, or in ~/.agentmemory/.env; setting it only inside the iii Docker container will not enable graph registration for the host worker.
#308 looks related from the user's point of view because graph extraction is skipped there too, but it is a different problem: SessionEnd is unreliable, so the extraction path may never run. This PR only fixes the misleading REST error handling around #338.
Tests
npm test -- test/api-graph.test.ts --reporter=dot
npm run build
Both pass locally.
I also ran git diff --check.
Note: the full suite still has existing failures in test/mcp-standalone.test.ts in this workspace. Those failures are on the standalone MCP/proxy path and are unrelated to the graph REST changes here.
Summary by CodeRabbit
-
Bug Fixes
- Enhanced error handling for knowledge graph operations, clearly distinguishing between disabled extraction and actual request failures.
- Improved user guidance when knowledge graph extraction is not enabled with clearer activation instructions.
-
Tests
- Added comprehensive test coverage for knowledge graph REST endpoints to ensure reliability.

Local branch:
Fork PR:
Fork decision:
Verification:
Notes:
Source: Source pull request number: 341 in rohitg00/agentmemory (URL omitted to avoid GitHub cross-reference)
Title: fix(graph): report trigger failures separately
Author: wyh0626
State: open
Draft: no
Merged: no
Head: wyh0626/agentmemory:codex/fix-graph-trigger-errors @ 177bd09
Base: main @ 1c8713f
Labels: (none)
Changed files: 0
Commits: 0
Created: 2026-05-13T15:57:13Z
Updated: 2026-05-17T09:42:42Z
Closed: (not closed)
Merged at: (not merged)
Original PR body:
Summary
Refs #338.
The graph REST endpoints were treating every graph trigger failure as if graph extraction was disabled. That made a real backend error, for example
iii::engine Function not found: mem::graph-stats, show up as503 Knowledge graph not enabled.This keeps the disabled-flag response, but only uses it when
GRAPH_EXTRACTION_ENABLEDis actually off. If the flag is on and the underlying graph function fails, the REST endpoint now returns a 500 with the function id and the original error message. That should make reports like #338 much easier to diagnose.I also added a startup log when graph extraction is off. The log calls out that
GRAPH_EXTRACTION_ENABLED=truehas to be set in the process running agentmemory, or in~/.agentmemory/.env; setting it only inside the iii Docker container will not enable graph registration for the host worker.#308 looks related from the user's point of view because graph extraction is skipped there too, but it is a different problem: SessionEnd is unreliable, so the extraction path may never run. This PR only fixes the misleading REST error handling around #338.
Tests
npm test -- test/api-graph.test.ts --reporter=dot npm run buildBoth pass locally.
I also ran
git diff --check.Note: the full suite still has existing failures in
test/mcp-standalone.test.tsin this workspace. Those failures are on the standalone MCP/proxy path and are unrelated to the graph REST changes here.Summary by CodeRabbit
Bug Fixes
Tests
Local branch:
Fork PR:
Fork decision:
Verification:
Notes: