pi-durable: gen_ai.conversation.id changes after a restart #25773
Description
The pi-durable integration reports gen_ai.conversation.id as <harnessId>:<conversationId>. harnessId is a random uuid that the SDK makes each time Harness.open() runs (packages/server-utils/src/ai/pi-durable/runs.ts). It stays in memory only. When a process restarts, or a Durable Object restarts after an eviction or a deploy, the Harness opens again on the same storage and gets a new uuid. Each run after the restart then shows as a new conversation in Sentry.
This affects all server SDKs that use persistent pi-durable storage (SQLite, JSONL). It occurs most on Cloudflare, because Durable Objects are often evicted. Also, two processes that use the same storage report different ids for the same conversation.
We cannot remove the prefix. pi-durable numbers conversations from 1 in each storage, so the bare numbers from different storages would merge into one conversation. pi-durable has no stable storage id that the SDK can use.
Reproduction: https://github.com/andreiborza/cf-pi-durable-objects. Two prompts give the same id. A third prompt, after a restart with ctx.abort(), gives a different id.
Activity
linear-code commentedon Oct 27, 2026
JS-4012
andreiborza commentedon Oct 27, 2026
pi-durable already has a stable id for this. Since 1.0.2, it keeps a UUIDv7 per conversation in the
pi.providerdocument (earendil-works/pi#10424). It stays the same after a reopen, it is unique across storages, and pi-durable sends it to pi-ai assessionId.The fix is to report this id as
gen_ai.conversation.id, and to keep<harnessId>:<conversationId>only as the fallback for versions without the document.github-actions commentedon Oct 28, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #25792, which was included in the 11.10.0 release.
fix(server-utils): Use the stored pi-durable session id as conversati…