{"version":"2.1.247","anchor":"deleting-a-message-from-a-large-transcript-now-actually-dele","canonical_anchor":"deleting-a-message-from-a-large-transcript-now-actually-dele","heading":"Deleting a message from a large transcript now actually deletes it","tier":"notice","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.247\/e\/deleting-a-message-from-a-large-transcript-now-actually-dele","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.247","markdown":"### Deleting a message from a large transcript now actually deletes it\n\nDeleting a message from a very long transcript now actually removes it.\n\n**What**\n\nOn the paged fallback used for big transcripts in the newer storage format, the deletion routine was handed the file's storage key twice instead of the message identifier, so it searched for the wrong value and never found the message. It now receives the identifier.\n\n**Details**\n\n- Affects transcripts using the v5 storage backend, on the slow paged removal path only; the fast path was unaffected.\n\n**Evidence**\n\n`removeByUuidSlowV5`\n\n- Area: Sessions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}