update forget implementation in mcp#773
Merged
graphite-app[bot] merged 1 commit intomainfrom Mar 9, 2026
Merged
Conversation
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-app | 07875ad | Mar 09 2026, 07:02 PM |
Contributor
Author
How to use the Graphite Merge QueueAdd the label Main to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
sohamd22
force-pushed
the
03-07-update_forget_implementation_in_mcp
branch
from
bf75808 to
15f1453
Compare
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
sohamd22
force-pushed
the
03-07-update_forget_implementation_in_mcp
branch
from
15f1453 to
541604f
Compare
Dhravya
approved these changes
Mar 9, 2026
Merge activity
|
### TL;DR Enhanced the `forgetMemory` method to try exact content matching first, then fall back to semantic search with a high similarity threshold for more precise memory deletion. ### What changed? The `forgetMemory` method now uses a two-step approach: first attempting exact content matching via the API, and if that fails with a 404, falling back to semantic search with a similarity threshold of 0.85. The search method also accepts an optional threshold parameter. Error messages now distinguish between exact matches and semantic matches, including similarity scores in the response. ### How to test? 1. Call `forgetMemory` with the exact content of an existing memory to verify direct deletion 2. Call `forgetMemory` with similar but not identical content to test the semantic search fallback 3. Call `forgetMemory` with completely unrelated content to verify the "no matching memory found" response 4. Verify that success messages indicate whether deletion used exact matching or semantic matching with similarity scores ### Why make this change? This approach provides more precise memory deletion by prioritizing exact matches while still offering a fallback for similar content. The high similarity threshold (0.85) ensures that only very similar memories are deleted when exact matches aren't found, reducing the risk of accidentally deleting unrelated memories.
graphite-app
bot
force-pushed
the
03-07-update_forget_implementation_in_mcp
branch
from
541604f to
07875ad
Compare
Comment on lines
+167
to
+177
| }) | ||
|
|
||
| return { | ||
| success: true, | ||
| message: `Successfully forgot memory (exact match) with ID: ${result.id}`, | ||
| containerTag: this.containerTag, | ||
| } | ||
| } catch (error: any) { | ||
| // If not 404, it's a real error - re-throw it | ||
| if (error?.status !== 404) { | ||
| throw error |
There was a problem hiding this comment.
Bug: The code incorrectly assumes this.client.memories.forget() returns an object with an id. Accessing result.id will cause a TypeError because the function likely returns void.
Severity: HIGH
Suggested Fix
Remove the assignment of the return value from this.client.memories.forget() to the result variable. Update the success message to indicate successful deletion without referencing a non-existent result.id, as the function does not appear to return any value.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: apps/mcp/src/client.ts#L164-L177
Potential issue: The code calls `this.client.memories.forget()` and assigns its return
value to `result`, then attempts to access `result.id`. Evidence from other parts of the
codebase suggests that `memories.forget()` returns `void` or `undefined`. This
discrepancy will cause a `TypeError` when `result.id` is accessed. The existing `catch`
block is not designed to handle a `TypeError`, so the function will throw an unhandled
error even when the memory deletion operation succeeds, breaking the intended
functionality of this new code path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
Enhanced the
forgetMemorymethod to try exact content matching first, then fall back to semantic search with a high similarity threshold for more precise memory deletion.What changed?
The
forgetMemorymethod now uses a two-step approach: first attempting exact content matching via the API, and if that fails with a 404, falling back to semantic search with a similarity threshold of 0.85. The search method also accepts an optional threshold parameter. Error messages now distinguish between exact matches and semantic matches, including similarity scores in the response.How to test?
forgetMemorywith the exact content of an existing memory to verify direct deletionforgetMemorywith similar but not identical content to test the semantic search fallbackforgetMemorywith completely unrelated content to verify the "no matching memory found" responseWhy make this change?
This approach provides more precise memory deletion by prioritizing exact matches while still offering a fallback for similar content. The high similarity threshold (0.85) ensures that only very similar memories are deleted when exact matches aren't found, reducing the risk of accidentally deleting unrelated memories.