test(core): regression guard for long relation_type values (#721)

[phernandez]

Summary

• edit_note fails on notes with long text around inline wikilinks (relation_type exceeds MaxLen) #721 reported edit_note failing on notes with >200 chars of prose preceding an inline [[wikilink]] — the parser extracts that prose as relation_type, which then violated the MaxLen(200) constraint on RelationType in the response model.
• Verified the bug no longer reproduces: commit 01cbad1 ("Allow long relation_type values in responses") removed the cap. The reported failure mode is already fixed on main.
• This PR adds a regression-guard integration test that exercises the exact scenario from edit_note fails on notes with long text around inline wikilinks (relation_type exceeds MaxLen) #721. If anyone reintroduces MaxLen on RelationType, the test fails immediately.

Why test-only

The original symptom (validation error → poisoned note) is fixed. The reporter's secondary suggestion — a parse_relation() heuristic to fall back to links_to when prose-before-link looks like a sentence — is a knowledge-graph quality improvement, not a correctness fix, and is intentionally out of scope here.

Test plan

• pytest test-int/mcp/test_long_relation_type_integration.py --no-cov — passes
• Confirmed: RelationType = Annotated[str, MinLen(1)] in schemas/base.py:181 (no MaxLen)
• Confirmed: 271-char prose-before-link reproduces the historical input shape; edit succeeds
• ruff check clean

Closes #721

🤖 Generated with Claude Code

[github-actions]

Claude finished @phernandez's task in 1m 23s —— View job

---

Code Review

• Gather context and understand the PR
• Read the new test file
• Check related schema/model files for context
• Review against team checklist
• Post final review

---

Summary: Clean, well-scoped regression guard. The module docstring is excellent — it explains the historical bug, the fix commit, and what's explicitly out of scope. The test follows project conventions and will catch any reintroduction of MaxLen on RelationType.

Team Checklist

Category	Status	Notes
Coding conventions (CLAUDE.md)	✅	Follows conventions
Python 3.12+ type annotations / async	✅	async with Client(...) pattern
100-char line length	✅	All lines within limit
No commented-out code	✅
Integration test added	✅	Placed correctly in test-int/mcp/
100% coverage maintained	✅	Test-only PR, no new production code
No DB/Alembic migration needed	✅	No schema changes
No hardcoded secrets	✅
Windows path compatibility	✅	No path comparisons
No emojis/unicode in output	✅
Local-first architecture preserved	✅

Minor observations

1. Assertion specificity (test_long_relation_type_integration.py:75)

assert "Edited note" in edit_result.content[0].text

Other tests (e.g., test_edit_note_integration.py) use the more specific "Edited note (append)" since the operation is append. The current assertion would pass even if the response message changed unexpectedly. Low-impact, but worth aligning:

assert "Edited note (append)" in edit_result.content[0].text

Fix this →

2. No len(content) == 1 guard on write_result (test_long_relation_type_integration.py:60)

write_text = write_result.content[0].text

Other integration tests first assert len(result.content) == 1 before indexing. Not critical since the test would still fail clearly on an IndexError, but it's inconsistent with surrounding tests.

3. No read-back verification (optional, not blocking)

The test proves edit_note doesn't raise a validation error, which is exactly the regression being guarded. A follow-up read_note call to confirm the long relation_type is properly indexed in the response model would add depth, but it's not required for the stated goal.

Verdict

Approve. The core regression guard is correct and sufficient. Observations 1 and 2 are cosmetic nits — either address them here or leave them; neither affects correctness or the guard's purpose.

[github-actions]

Claude finished @phernandez's task in 1m 8s —— View job

---

Code Review

• Gather context and understand the PR
• Read the updated test file (post-fixup commit)
• Check related schema/model files for context
• Review against team checklist
• Post final review

---

Summary: The fixup commit (e1376ca) addressed both nits from the previous review. The test is clean, well-scoped, and ready to merge.

What changed in the fixup commit

Previous	Updated
assert "Edited note" in edit_result.content[0].text	assert "Edited note (append)" in edit_result.content[0].text
No len() guard before write_result.content[0]	assert len(write_result.content) == 1 added at line 60
No len() guard before edit_result.content[0]	assert len(edit_result.content) == 1 added at line 76

Both indexing sites are now guarded, and the edit assertion matches the specificity used in other edit_note integration tests.

Schema verification

RelationType in src/basic_memory/schemas/base.py:181:

RelationType = Annotated[str, MinLen(1)]
# No MaxLen - matches DB Text column which has no length restriction

No MaxLen — the regression guard is testing the right constraint.

Team Checklist

Category	Status	Notes
Coding conventions (CLAUDE.md)	✅	Literate module docstring explains the bug, fix commit, and explicit out-of-scope
Python 3.12+ type annotations / async	✅	async def + @pytest.mark.asyncio
SQLAlchemy 2.0 / FastAPI / Typer	N/A	Test-only PR
100-char line length	✅	All lines within limit
No commented-out code	✅
Integration test added	✅	Correctly placed in test-int/mcp/
100% coverage maintained	✅	No new production code
No DB/Alembic migration needed	✅	No schema changes
No hardcoded secrets	✅
Windows path compatibility	✅	No path comparisons
No emojis/unicode in output	✅
Local-first architecture preserved	✅

Verdict

Approve. All previous nits resolved. The regression guard is correct, the len() guards are consistent with surrounding tests, and the assertion specificity now matches the operation. No further changes needed.