Developer API memories pagination returns HTTP 500 for specific offsets

[supercontemn]

Summary

GET /v1/dev/user/memories can consistently return HTTP 500 for specific memory offsets, while nearby offsets and other memory records return successfully. This appears to be either malformed memory data or a pagination/serialization bug in the Developer API memory list path.

Endpoint

GET /v1/dev/user/memories?limit=<n>&offset=<n>

Observed behavior

• The live API returns most memories cleanly.
• Two offsets, 7 and 8, consistently return HTTP 500.
• The failure reproduces with limit=1 and with larger page sizes where the affected offsets are included.
• A local importer using one-by-one pagination can continue past the failing windows and import all reachable memories, but it cannot recover the failing records.

Expected behavior

The endpoint should not fail the whole request with HTTP 500 for specific records or pagination windows.

Expected options:

• return the records normally,
• repair/skip invalid records server-side,
• or return a structured error that does not break unrelated pagination.

Minimal reproduction pattern

# Works for normal offsets
GET /v1/dev/user/memories?limit=1&offset=0

# Consistently fails in this case
GET /v1/dev/user/memories?limit=1&offset=7
GET /v1/dev/user/memories?limit=1&offset=8

Impact

Any integration syncing memories via offset pagination can get stuck or silently miss records when a page intersects the failing offsets. This affects Obsidian sync plugins, MCP integrations, local backup/import scripts, and other Developer API clients.

Current workaround

The local importer now:

• walks memories using limit=1,
• logs failing offsets,
• continues past HTTP 500 windows where possible,
• imports all reachable records.

This is only a client-side recovery pattern. The backend still needs to handle or repair the affected memory records/pagination path.