What happens
On hardware, 27 August: a Shot PinPointStudio declines to record stays in this device's queue as still to send, indefinitely. The row never settles and the session cannot be cleared.
Why
⛔ There is no way for a host to say it did not keep a Shot. An issued Shot is a fact — I7 makes t0 never-revisable and there is deliberately no withdraw — but a host can still decline to record one, through its corroboration rule or because its pipeline was busy. PPCP has no message for that, so the device waits for a capture_committed that will never come (5.14h), and 5.14g gives the transfer no exit.
⚠ This is the fourth instance of the same gap, which is why it is one item and not four:
| Where |
The statement that cannot be made |
| A host declining a Shot |
"I did not keep this" |
| A device disarmed at the handset |
"I stopped, and nothing is wrong" |
| The settle timeout |
"the source exists and produced nothing" (closed by source_not_delivering) |
A stream_open we will not honour yet |
"declined, not implemented" |
What we can do without the protocol
Nothing that makes it correct — but the device should not present an unsendable Capture as actively sending. A transfer with no progress and no acknowledgement is not "Sending 0%".
What actually closes it
shot_disposition — a host states what it did with a Shot. Agreed in shape with PinPointStudio 27 Aug; to be raised jointly after enough real sessions to say how often a host genuinely cannot record. Recorded in the shared learnings document §1.3/§1.4.
What happens
On hardware, 27 August: a Shot PinPointStudio declines to record stays in this device's queue as still to send, indefinitely. The row never settles and the session cannot be cleared.
Why
⛔ There is no way for a host to say it did not keep a Shot. An issued Shot is a fact — I7 makes
t0never-revisable and there is deliberately no withdraw — but a host can still decline to record one, through its corroboration rule or because its pipeline was busy. PPCP has no message for that, so the device waits for acapture_committedthat will never come (5.14h), and 5.14g gives the transfer no exit.⚠ This is the fourth instance of the same gap, which is why it is one item and not four:
source_not_delivering)stream_openwe will not honour yetWhat we can do without the protocol
Nothing that makes it correct — but the device should not present an unsendable Capture as actively sending. A transfer with no progress and no acknowledgement is not "Sending 0%".
What actually closes it
shot_disposition— a host states what it did with a Shot. Agreed in shape with PinPointStudio 27 Aug; to be raised jointly after enough real sessions to say how often a host genuinely cannot record. Recorded in the shared learnings document §1.3/§1.4.