Bug: edit_note MCP tool rejects payload with null/undefined optional fields

[bm-clawd]

Problem

edit_note via MCP rejects payloads that include optional fields set to null or undefined. For example, an append operation that includes find_text: null and section: null fails with an invalid payload error.

Reproduction

This call fails:

{
  "identifier": "conversations-2026-02-25",
  "operation": "append",
  "content": "### 10:00\n...",
  "find_text": null,
  "section": null,
  "expected_replacements": null,
  "output_format": "json"
}

This call succeeds:

{
  "identifier": "conversations-2026-02-25",
  "operation": "append",
  "content": "### 10:00\n...",
  "output_format": "json"
}

Impact

• Breaks the openclaw-basic-memory plugin's auto-capture hook (indexConversation → editNote → append to daily conversation note)
• Gateway error log: basic-memory: conversation append failed — invalid edit_note payload
• Worked in previous BM versions — likely a regression from stricter MCP input validation

Workaround

Plugin-side fix applied in openclaw-basic-memory@8caaf86: strip undefined optional fields before sending. But BM should also handle this gracefully — null/undefined optional fields should be ignored, not rejected.

Expected Behavior

Optional fields (find_text, section, expected_replacements) that are null or absent should be silently ignored for operations that don't use them (append, prepend).

[claude]

Claude finished @bm-clawd's task in 4m 3s —— View job • claude/issue-606-20260225-1524 • Create PR ➔

---

Analysis: edit_note rejects null optional fields — Fixed

Triage:

• Type: Bug (regression in MCP input validation)
• Component: MCP tools (edit_note)
• Priority: High (breaks plugin integrations like openclaw-basic-memory)
• Complexity: Simple

Root Cause:

expected_replacements was typed as int = 1 (non-optional). FastMCP generates JSON Schema from Python type annotations, so this became {"type": "integer"} in the tool schema — which rejects null. When a client sends expected_replacements: null, MCP schema validation rejects the entire payload before the function body runs.

find_text and section were already Optional[str], so they correctly allow null in the schema.

Fix (src/basic_memory/mcp/tools/edit_note.py):

1. Changed expected_replacements: int = 1 → expected_replacements: Optional[int] = None so FastMCP generates {"anyOf": [{"type": "integer"}, {"type": "null"}]} allowing null.
2. Added effective_replacements = expected_replacements if expected_replacements is not None else 1 inside the function to preserve the default-1 behaviour.
3. Updated all internal references to use effective_replacements.

Regression test added in tests/mcp/test_tool_edit_note.py — test_edit_note_append_with_null_optional_fields — covering the exact payload shape from the issue.

Tasks

• Analyze issue
• Find root cause
• Fix expected_replacements type annotation to allow null
• Update internal logic to treat null as the default value (1)
• Add regression test for null optional fields
• Push changes and create PR

|