Fleet episode-id namespace split: record_external_episode returns a UUID, fleet_get_episode rejects it (expects a ULID)

[Regis-RCR]

TL;DR: record_external_episode returns an episode_id shaped like a UUID. fleet_get_episode rejects that same id with invalid episode_id (expected a ULID). An episode created through one fleet tool cannot be fetched through its sibling getter: the getter rejects the UUID-shaped id that the create call returns.

Environment

• memtrace 0.6.11, macOS arm64
• fleet episode tools via memtrace mcp

Repro

record_external_episode(repo_id, source_type="external_...", source_id, ...)
  -> episode_id: deb0a10b-5920-4b8d-b130-d54c8762cfe5       (UUID shape)

fleet_get_episode(episode_id="deb0a10b-5920-4b8d-b130-d54c8762cfe5")
  -> error: invalid episode_id (expected a ULID): deb0a10b-5920-4b8d-b130-d54c8762cfe5

fleet_get_episode expects a ULID, but record_external_episode returns a UUID-shaped id, so the id it returns does not resolve through fleet_get_episode.

Expected

An episode id returned by record_external_episode should be fetchable via fleet_get_episode. Either the external-episode path returns a ULID like the rest of the fleet episode surface, or fleet_get_episode accepts both shapes, or the docs make clear that external episodes are a separate namespace not addressable through that getter.

Actual

The two id formats do not interoperate. A caller that records an external episode, captures the returned episode_id, then tries to read it back through fleet_get_episode hits a hard parse rejection. Nothing in the record_external_episode response signals that its id belongs to a namespace the getter cannot read. The error is accurate, but the surprise is upstream: the create call handed back an id the matching get call refuses.

Why it matters

The create-then-fetch loop is a common pattern: record an episode, hold the id, look it up later. That loop silently breaks for external episodes. A caller has no obvious way to know the UUID is a dead end short of trying the fetch and reading the error. If external episodes are deliberately a distinct namespace, that is a reasonable design, but it should be visible at the API boundary rather than discovered through a failed fleet_get_episode.

Ask

Align the id formats across the fleet episode surface (mint a ULID from record_external_episode, or teach fleet_get_episode to resolve the external-episode UUID), or document the namespace split and point external-episode callers at whatever getter resolves the UUID. Happy to send a PR once the intended behavior is settled.

[blocksorg]

Mention Blocks like a regular teammate with your question or request:

@blocks can you add technical details to this issue?
@blocks make the following changes ...
@blocks create an issue from what was mentioned in the following comment ...
@blocks explain the following code ...
@blocks are there any security or performance concerns?

Run @blocks /help for more information.

Workspace settings | Disable this message

[Alex793x]

Confirmed, and it was worse than a namespace split: the UUID returned by record_external_episode was minted purely for the response and persisted nowhere, so there was nothing for any getter to resolve — the create-then-fetch loop was structurally dead.

Fixed in v0.6.17 along the lines you suggested: record_external_episode now mints a ULID and mirrors the episode into the same store fleet_get_episode reads, so the returned episode_id round-trips immediately and across restarts. parent_episode_id accepts both shapes so ids captured from older versions don't break. The create→fetch loop is a regression test now.