{"version":"2.1.238","anchor":"sdk-command-lifecycle-adds-a-refused-outcome","canonical_anchor":"sdk-command-lifecycle-adds-a-refused-outcome","heading":"SDK command lifecycle adds a \"refused\" outcome","tier":"internal","area":"SDK","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238\/e\/sdk-command-lifecycle-adds-a-refused-outcome","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.238","markdown":"### SDK command lifecycle adds a \"refused\" outcome\n\nA message from another session that your receive policy turns away is now reported as refused.\n\n**What**\n\nThe internal SDK event stream that reports command progress gained a `refused` state for a peer message turned away by the session's receive-side policy before it ever joined the queue, so it is never preceded by \"queued\". The existing `discarded` state now also covers a session ending while such a message is still held.\n\n**Details**\n\n- The schema documents a known gap: the queue's own admission checks (rate limit, duplicate collapse, loop guard, queued-peer cap) can leave a message in \"queued\" with no terminal state.\n- The git-operation event docs now note that pushing several branches emits one event per branch.\n\n**Evidence**\n\n`declined by the session's receive-side policy before entering the queue`\n\n- Area: SDK\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}