Re-adding a retained cloud project does not index its existing notes

[phernandez]

Summary

Re-adding a cloud project after delete_project(delete_notes=false) creates a new project record but does not index the retained note files, so the content remains inaccessible through MCP.

Discovered during the 2026-07-16 live acceptance run against basic_memory_development with Basic Memory revision b7142528752f1727056dba924b348abc84b407f9 deployed through Basic Memory Cloud revision 17810e7bd5ad0f41841308150b16acd233a3bf79.

Reproduction

1. Create a cloud project and write two notes.
2. Call delete_project with delete_notes=false.
3. Wait for the returned delete job to complete.
4. Verify the project and graph rows are removed while both markdown objects remain in cloud storage.
5. Call create_memory_project with the same project name and path.
6. Poll read_note for the retained paths.

Observed project:

• original external ID: c4fda783-40d8-4e0c-8eae-a8490f38061c
• recreated external ID: b8511385-3569-4a5b-aa24-fbd47c50e960
• path: /acceptance-20260716-1558

Observed result

• create_memory_project returned created=true immediately.
• The recreated project appeared in list_memory_projects on every poll.
• After 90 seconds and 13 attempts, both retained paths still returned null from read_note.
• Neon contained the recreated project row and zero entities for that project.
• Tigris still contained both retained markdown objects with their original content.
• No project-index workflow was enqueued for the recreated project.

This contradicts the delete_project(delete_notes=false) response, which says: Re-add the project to access its content again.

Root-cause investigation

This is owned by Basic Memory rather than the Cloud delete implementation:

• create_memory_project calls ProjectClient.create_project(...) and invalidates the workspace project cache.
• It does not call the existing ProjectClient.index(...) method after creation.
• Basic Memory Cloud already implements /v2/projects/{project_id}/index by enqueueing the PGQueuer project-index workflow for S3-backed projects.
• The Cloud retention and purge paths behaved correctly: delete_notes=false retained objects, and delete_notes=true later removed them.

Classification: indexing regression / incomplete project lifecycle contract in Basic Memory.

Suggested fix

After a successful create_memory_project, trigger project indexing using the newly returned external ID. In cloud/factory mode this should call the existing index endpoint and enqueue PGQueuer; for local projects it should run through the normal project-index path.

The returned result should expose the index acceptance or workflow/job identifier when indexing is asynchronous, rather than stating the project content is available before indexing has been accepted.

Add a regression test covering:

1. delete a populated project with delete_notes=false,
2. recreate the same name/path,
3. assert an index is triggered,
4. wait for completion,
5. read/search the retained notes successfully.

Acceptance criteria

• Re-adding a retained project automatically triggers indexing.
• Retained notes become readable and searchable without an out-of-band API call.
• Cloud creation returns the indexing workflow/job identifier or an explicit indexing state.
• New empty projects remain idempotent and do not fail when the index finds zero files.

[claude]

Claude finished @phernandez's task in 9m 0s —— View job

---

Claude ran into an environment issue while finishing up

Todo list:

• Gather context: read issue body
• Understand request (implementation + regression test)
• Investigate create_memory_project MCP tool and ProjectClient
• Investigate ProjectClient.index(...) / index endpoint usage
• Implement fix: trigger indexing after project creation
• Add regression tests
• Run lint/typecheck/tests — blocked, see below
• Push branch and provide PR link — blocked, see below

What was implemented

Root cause confirmed: create_memory_project (src/basic_memory/mcp/tools/project_management.py) called ProjectClient.create_project(...) but never called the existing ProjectClient.index(...) (src/basic_memory/mcp/clients/project.py), which hits POST /v2/projects/{id}/index. That route already works for local projects (LocalProjectIndexCommand, synchronous when run_in_background=False) and for cloud projects (PGQueuer enqueue, per the issue). Nothing else triggers indexing for a project created through this tool, so retained note files (from delete_project(delete_notes=false)) stayed invisible to read_note/search_notes.

Changes (commit f780024, on claude/issue-1084-20260716-1658, not yet pushed — see below):

• src/basic_memory/mcp/tools/project_management.py: after a new project record is created, call project_client.index(external_id, run_in_background=False) so local projects are indexed synchronously (immediately searchable/readable) and cloud can still enqueue its async workflow. The result (file counts locally, or a message/status/job id from cloud) is surfaced in both the JSON output ("indexing" key) and the text output (Indexing: section). Idempotent "already exists" responses are unaffected.
• test-int/mcp/test_project_management_integration.py: new regression test test_recreate_project_after_delete_notes_false_indexes_retained_notes — creates a project, writes a note, deletes with delete_notes=false, re-adds the same name/path, and asserts the retained note is immediately readable via read_note and discoverable via search_notes with no extra index call. Also added test_create_project_indexing_is_idempotent_for_empty_projects covering the "0 files found" case per the acceptance criteria.
• tests/mcp/test_tool_project_management.py: three existing unit tests that mock ProjectClient.create_project against a bare (non-ASGI-backed) fake HTTP client now also mock ProjectClient.index, since the fix now calls it unconditionally on project creation.

Blocked steps

1. Lint/typecheck/tests: this session's Bash tool requires approval for any command that executes an interpreter (uv run ..., just ..., python3 ...), and no approval was available in this run. I was not able to run just fast-check, just fast-test, or the new tests. I traced the change carefully by hand (including how run_in_background=False behaves in LocalProjectIndexCommand.index_project and the existing bm doctor command, which already exercises this exact synchronous index → search → status pattern), but this needs an actual test run before merging. Please run just fast-check and uv run pytest test-int/mcp/test_project_management_integration.py tests/mcp/test_tool_project_management.py -v (or update my --allowedTools to permit uv/just/python3) to confirm.
2. Push: git push failed with a permissions error — remote: Permission to basicmachines-co/basic-memory.git denied to github-actions[bot] (403), on two attempts. The commit exists locally on claude/issue-1084-20260716-1658 but is not on the remote, so I can't provide a PR link yet. This looks like a repo/App permission issue unrelated to the code change — someone with push access may need to look at it, or re-run me once that's resolved.

[phernandez]

@claude make a PR the issue triage got stuck

[claude]

Claude finished @phernandez's task in 6m 10s —— View job

---

Claude ran into an environment issue again while finishing up

Todo list:

• Gather context: read issue body + prior stuck attempt's findings
• Re-investigate create_memory_project MCP tool and ProjectClient.index(...)
• Implement fix: trigger indexing after project creation
• Update existing unit tests that mock ProjectClient.create_project
• Add regression tests
• Run lint/typecheck/tests — blocked, see below
• Push branch and provide PR link — blocked, see below

What was implemented

Same root cause as diagnosed previously: create_memory_project (src/basic_memory/mcp/tools/project_management.py) called ProjectClient.create_project(...) but never called the existing ProjectClient.index(...) (src/basic_memory/mcp/clients/project.py), which hits POST /v2/projects/{id}/index. That route already works for local projects (LocalProjectIndexCommand, synchronous when run_in_background=False, matching the pattern already used by basic-memory doctor) and, per this issue, for cloud projects via a PGQueuer enqueue. Nothing else triggered indexing for a project created through this tool, so retained note files from delete_project(delete_notes=false) stayed invisible to read_note/search_notes.

Changes (commit 09d92fe, on claude/issue-1084-20260716-1732, not yet pushed — see below):

• src/basic_memory/mcp/tools/project_management.py: after a new project row is created, create_memory_project now calls project_client.index(external_id, run_in_background=False). Local projects index synchronously so retained content is immediately readable/searchable; cloud can still enqueue its async workflow. The outcome (file counts, a scheduled/async status, or an error) is surfaced via a new "indexing" key in JSON output and an Indexing: section in text output, instead of implying the content is already available before indexing happened. Indexing failures are reported rather than raised, since the project record was already created successfully either way.
• test-int/mcp/test_project_management_integration.py: added test_recreate_project_after_delete_notes_false_indexes_retained_notes (creates a project, writes a note, deletes with delete_notes=false, re-adds the same name/path, asserts the retained note is immediately readable via read_note and discoverable via search_notes with no extra index call) and test_create_project_indexing_is_idempotent_for_empty_projects (asserts a brand-new empty project directory indexes cleanly with 0 files, per the acceptance criteria).
• tests/mcp/test_tool_project_management.py: the three existing unit tests that mock ProjectClient.create_project against a bare (non-ASGI-backed) fake HTTP client now also mock ProjectClient.index, since the fix calls it unconditionally after project creation.

Blocked steps

1. Lint/typecheck/tests: this session's Bash tool requires approval for any command that executes an interpreter (just ..., ruff ..., python3 ...) or does network I/O (git fetch), and no approval was available in this run — same restriction as the prior attempt. I traced the change carefully by hand against the existing synchronous local-index pattern in doctor.py/command_utils.py, but this needs an actual run before merging. Please run just fast-check and uv run pytest test-int/mcp/test_project_management_integration.py tests/mcp/test_tool_project_management.py -v (or update the allowed tools to permit uv/just/python3/ruff) to confirm.
2. Push: git push (via the provided git-push.sh helper) failed again with remote: Permission to basicmachines-co/basic-memory.git denied to github-actions[bot] (403). The commit exists locally on claude/issue-1084-20260716-1732 but is not on the remote, so I can't provide a working compare/PR link — the branch doesn't exist on GitHub yet. This is a repo/App installation permission issue, not something fixable from within this sandbox. Someone with push access (or an updated App permission) will need to either push this branch or re-run me once that's resolved.