You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(think): preserve attachment fetchMetadata through messenger serialization (#1833) (#1839)
serializableMessengerEvent stripped everything except id/mediaType/name/
size/text/url from attachments before handing events to sub-agent DOs,
discarding fetch, raw, and the platform identifier. For adapters like
@chat-adapter/telegram the file id lives only in fetchMetadata.fileId and
the top-level id is never set, so attachments were irretrievable inside a
sub-agent.
Add a serialization-safe fetchMetadata field to MessengerAttachment,
preserve it through serializableMessengerEvent, and carry it through
toMessengerAttachment while backfilling the top-level id from a known
metadata key (id/fileId/mediaId/fileUniqueId).
Co-authored-by: Sunil Pai <18808+threepointone@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Preserve attachment `fetchMetadata` through messenger event serialization so sub-agents can re-fetch files.
6
+
7
+
When a conversation resolver routes a thread to a sub-agent Durable Object, the messenger event is run through `serializableMessengerEvent()` before crossing the DO boundary. That serialization previously dropped everything except `id`, `mediaType`, `name`, `size`, `text`, and `url` from each attachment — discarding `fetch`, `raw`, and (for adapters that store their platform identifier there) the only remaining handle on the file.
8
+
9
+
For adapters like `@chat-adapter/telegram`, the file identifier lives exclusively in `fetchMetadata.fileId` and the top-level `id` is never populated, so photos became irretrievable inside a sub-agent (`attachment.id` and `attachment.fetch` were both missing).
10
+
11
+
`MessengerAttachment` now carries a serialization-safe `fetchMetadata?: Record<string, string>` field that survives the sub-agent hop. `toMessengerAttachment()` copies `fetchMetadata` from the underlying Chat SDK attachment and backfills the top-level `id` from a known metadata key (`id`, `fileId`, `mediaId`, `fileUniqueId`) when the adapter doesn't set one. A downstream agent can use `fetchMetadata` together with the adapter's `rehydrateAttachment()` to reconstruct the download closure.
0 commit comments