Raised by PinPointStudio in the preview handover, 28 August 2026, §2.3 — the ⚠ they left behind after removing a call that could only ever fail.
The two halves of link_bind, and nobody owns it on purpose
ENC 2.1 has a dialler mint a 16-byte link id and write a link_bind as the first frame on each bulk channel. This application does that twice over, in two places, one of which is switched off:
| |
|---|
PpcpTransport.openChannel(_:) (Sources/Platform/Network/PpcpTransport.swift:549) | Mints the link id and writes the 2.1d frame itself. This is the one that runs. |
DevicePeer.setLinkId / .openChannel (Packages/Core/…/Ppcp/DevicePeer.swift:597, :605) | The engine's half. setLinkId is called nowhere in the application — its only caller anywhere is SessionBundleTests.swift:387. |
⛔ So the engine holds no link id, and ppcp_peer_open_channel() refuses on exactly that (ppcp_peer.c:899). HostLinkSession.openPreviewChannel called it anyway; the refusal was surfaced as no_preview_channel, and src:camera:wide was refused on every connect while its third channel sat up and working. Removed in 2f604b1.
Why it is still open after the removal
The removal made preview work. It did not decide anything: the answer today is "the transport owns it, silently", discoverable only by reading the comment at HostLinkSession.swift:668 or by losing two days.
⚠ DevicePeer.setLinkId is now dead code that looks live.LinkBinder's own doc comment still says "the dialler half is DevicePeer.setLinkId and .openChannel" — which is the exact reading that produced the defect.
What is being asked
Decide which layer owns link_bind, and make the tree say so:
- The transport owns it — then delete
DevicePeer.setLinkId and DevicePeer.openChannel, or mark them unused-by-design, and correct LinkBinder's comment. - The engine owns it — then call
setLinkId with the transport's minted id and let peer.openChannel write the frame.
⚠ Not a preview issue. It governs every bulk channel, and the next one added will meet the same trap.
Exit criterion
One owner, named at the site, with no reachable API for the other. A reader who has not read this issue cannot make the mistake 2f604b1 fixed.
Raised by PinPointStudio in the preview handover, 28 August 2026, §2.3 — the ⚠ they left behind after removing a call that could only ever fail.
The two halves of
link_bind, and nobody owns it on purposeENC2.1 has a dialler mint a 16-byte link id and write alink_bindas the first frame on each bulk channel. This application does that twice over, in two places, one of which is switched off:PpcpTransport.openChannel(_:)(Sources/Platform/Network/PpcpTransport.swift:549)DevicePeer.setLinkId/.openChannel(Packages/Core/…/Ppcp/DevicePeer.swift:597,:605)setLinkIdis called nowhere in the application — its only caller anywhere isSessionBundleTests.swift:387.⛔ So the engine holds no link id, and
ppcp_peer_open_channel()refuses on exactly that (ppcp_peer.c:899).HostLinkSession.openPreviewChannelcalled it anyway; the refusal was surfaced asno_preview_channel, andsrc:camera:widewas refused on every connect while its third channel sat up and working. Removed in2f604b1.Why it is still open after the removal
The removal made preview work. It did not decide anything: the answer today is "the transport owns it, silently", discoverable only by reading the comment at
HostLinkSession.swift:668or by losing two days.⚠
DevicePeer.setLinkIdis now dead code that looks live.LinkBinder's own doc comment still says "the dialler half isDevicePeer.setLinkIdand.openChannel" — which is the exact reading that produced the defect.What is being asked
Decide which layer owns
link_bind, and make the tree say so:DevicePeer.setLinkIdandDevicePeer.openChannel, or mark them unused-by-design, and correctLinkBinder's comment.setLinkIdwith the transport's minted id and letpeer.openChannelwrite the frame.⚠ Not a preview issue. It governs every bulk channel, and the next one added will meet the same trap.
Exit criterion
One owner, named at the site, with no reachable API for the other. A reader who has not read this issue cannot make the mistake
2f604b1fixed.