{"version":"2.1.242","anchor":"interrupt-behaviour-for-held-sends-is-now-written-down","canonical_anchor":"interrupt-behaviour-for-held-sends-is-now-written-down","heading":"Interrupt behaviour for held sends is now written down","tier":"internal","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242\/e\/interrupt-behaviour-for-held-sends-is-now-written-down","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242","markdown":"### Interrupt behaviour for held sends is now written down\n\nThe control protocol now spells out that interrupts keep held messages queued unless you cancel them.\n\n**What**\n\nThe control-protocol schema now explains what happens to a message a client is still holding back: a plain interrupt leaves it held and lists it under `still_queued`, while cancelling queued messages withdraws it and reports it under `cancelled`.\n\n**Details**\n\n- The same message can also be withdrawn on its own with `cancel_async_message`.\n- Today the only such hold is a message waiting for the session to take the initial upload from that machine.\n- A hosted-session driver follows a cancellation with a `command_lifecycle` frame marked `cancelled` when its own sweep cancels a send it had already delivered.\n- The behaviour is advertised to clients through the `interrupt_cancel_queued_v1` capability.\n\n**Evidence**\n\n`behind a send gate (today: waiting for the session to take the initial upload from that machine)`\n\n- Area: Elsewhere\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}