{"version":"2.1.275","anchor":"assistant-transcript-entries-now-carry-request-id-and-struct","canonical_anchor":"assistant-transcript-entries-now-carry-request-id-and-struct","heading":"Assistant transcript entries now carry request_id and structured error\/uuid\/timestamp fields directly","tier":"internal","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275\/e\/assistant-transcript-entries-now-carry-request-id-and-struct","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275","markdown":"### Assistant transcript entries now carry request_id and structured error\/uuid\/timestamp fields directly\n\nAssistant transcript entries now explicitly store a request_id alongside error, uuid, and timestamp\n\n**What**\n\nThe internal code that builds each assistant message entry in a conversation transcript was rewritten to explicitly set its fields: `type`, `message`, `uuid`, `timestamp`, `error`, and, when available, `request_id`. Previously this was built by copying the whole input object and only removing one field; now each field is set directly.\n\n**Why**\n\nThis makes transcript entries carry a clear, explicit `request_id` when one exists, which is useful for tracing a given assistant message back to the specific request that produced it, rather than relying on whatever happened to be present in the original object.\n\n- Area: Elsewhere\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 0\/5"}