[leodurandfr]

When the network path under the accesspoint connection goes away without a FIN or an RST, every track load fails on its audio key until the pong ack check notices, which takes 120 to 240 s after the last PongAck. This PR replaces such a connection as soon as an audio key goes unanswered, and bounds the pong ack check to 140 s.

What goes wrong

• KeyProvider.Request waits 15 s for an answer and fails (failed retrieving audio key: context deadline exceeded). Nothing closes the connection on that timeout and the player does not retry a load, so the next load's key request goes out on the same dead connection and fails the same way. The 15 s timeout was added in 117b929 for Shannon connection is not re-established on failure #88, so that a request on a broken connection fails instead of waiting forever; it does not replace the connection.
• The accesspoint pings and the device answers, so the device has no ping of its own to probe the connection with. All it can do is bound the wait for the next PongAck. The check runs on a 120 s ticker and drops the connection once the last PongAck is more than 120 s old, so a silent connection is dropped at the second tick after its last PongAck, 120 to 240 s later (240 to 360 s after a reconnection that has carried no PongAck yet, since a reconnection sets the last PongAck 120 s in the future). The bound is also the expected ping interval itself, with no margin, so a PongAck that comes a moment late drops a working connection whenever a tick falls in between.

Measured on a Raspberry Pi 5 with two links on the same LAN, by disconnecting the wired one (nmcli device disconnect eth0) while Wi-Fi kept LAN and internet access, with skips sent from the Spotify macOS app as a Connect remote. The build was v0.10.5 with #420, #421 and the two fixes I am sending separately (HTTP/2 health check, dealer pong timeout), but not this PR:

12:16:52  eth0 disconnected
12:17:37  next
12:17:52  failed load spotify:track:77lPC0YqxUODd674qz9LmV ... failed retrieving audio key: context deadline exceeded
12:18:23  failed load spotify:track:0xLIu53VONIKcPKcwtBBkd ... failed retrieving audio key: context deadline exceeded   (the player's own advance)
12:18:32  next
12:18:48  failed load spotify:track:25AT3BJHt4jtL3JYoZbqVK ... failed retrieving audio key: context deadline exceeded
12:19:20  did not receive last pong ack from accesspoint, 173s passed
12:19:20  authenticated AP                                   (71 ms later)
12:19:48  next
12:19:48  loaded track "PARADIGM"                           (0.25 s after the skip)

/status reported buffering for 130 s, from the first skip to the first load after the new connection. The new connection authenticated in 71 ms, so that time went into waiting for the old one to be dropped.

Changes

1. fix: drop an accesspoint connection that leaves an audio key unanswered. A key request left unanswered for 5 s drops the connection it was written to, so recvLoop's reconnection replaces it, and the request is sent once more with 15 s to be answered. librespot gives up on an audio key after 1.5 s (audio_key.rs); 5 s still leaves a live connection plenty of time, and a false alarm costs one reconnection. A load whose key never comes now fails after about 20 s instead of 15 s.
   • Accesspoint.SendConn returns the ConnID the packet was written to, and DropConn(id) closes that connection only if it is still the current one, so a request that gives up late cannot close the replacement. DropConn takes connMu with TryRLock: only a connection in progress holds it for writing, and that one is already replacing the connection, so the caller never waits out a backoff.
   • A packet written to a connection this side has just closed waits for the replacement and is sent on it. Without this, the retry sent right after the drop often reached the closed socket before recvLoop noticed, and failed as a send error. recvLoop's own Pong is written directly, since recvLoop is what does the replacing.
   • Each attempt is a new request with its own sequence number, so a late answer to the first one cannot be taken for the second.
   • A request ended by its caller (a load cancelled by a skip) drops nothing and is not retried.
   • NewAudioKeyProvider takes the four methods it uses as an interface, which *ap.Accesspoint satisfies, so the retry can be tested against a fake.
2. fix: drop a silent accesspoint connection 140 s after its last PongAck. The connection is dropped 120 s plus a 20 s margin after its last PongAck, a new connection counting as one. A timer armed for that deadline replaces the ticker, so the tick phase no longer adds up to another 120 s. librespot runs the same exchange with a deadline per step and a 20 s safety margin on each (session.rs). The check now drops the connection its deadline belongs to through DropConn; the old closeConn could wait for a reconnection in progress and then close the connection that reconnection had just made.

The second commit uses DropConn from the first. The first builds and passes the tests on its own, and so does the second on top of it.

On the device

Same setup and cut, on the same build plus this PR's two commits:

13:02:04  eth0 disconnected
13:02:35  next
13:02:40.635  no aes key for file 5ea630077ebb962bd493e9e65bcfd8047b8a2967 after 5s, retrying on a new accesspoint connection
13:02:40.650  failed to connect to AP ap-gew1.spotify.com:443, retrying with a different AP ... connection refused
13:02:40.704  authenticated AP
13:02:40.823  loaded track "Tell Me How"

	without	with
loads after the first skip	3 failed, buffering for 130 s	loaded 5.8 s after the skip
accesspoint connection replaced	149 s after the cut (pong ack check, 173 s after the last PongAck)	37 s after the cut, at the first unanswered key
later skips during the cut	failed until the connection was replaced	loaded 0.26 s and 0.37 s after the skip

This run did not exercise the 140 s PongAck deadline, since the key retry replaced the connection first. Over the 51 minutes the build then ran on the device, on accesspoint connections that lived up to 21 minutes, the PongAck check never fired, so 140 s was not tighter than the accesspoint's actual ping interval there.

An expected side benefit, not measured: before this PR, the device's journal logged did not receive last pong ack from accesspoint, 120s passed six times between 2026-11-04 and 2026-11-07. Two came 87 s and 12 s after the wired link was disconnected on purpose. The other four came with no change to the wired link in the journal (one came three minutes after the Wi-Fi link was reconnected), and a new connection authenticated within 0.4 s each time. PongAcks are not logged, so whether those four connections were still alive cannot be told; if they were, the 20 s margin removes those reconnections.

Tested

• Unit tests (test_unit), each seen failing with its part undone:
  • TestKeyRequestIsRetriedOnANewConnectionWhenTheFirstWentSilent: the key comes on the second connection, the first one is dropped. With the single 15 s attempt it fails with aes key request timed out: context deadline exceeded.
  • TestKeyRequestEndedByItsCallerKeepsTheConnection: a caller's deadline drops nothing and sends nothing again.
  • TestDropConnClosesOnlyTheConnectionItNames, TestDropConnDoesNotWaitForAReconnection.
  • TestSendAfterDropConnWaitsForTheReplacement: drops the connection of a running recvLoop and sends at once, 300 times. Without the wait it fails on the first drop with io: read/write on closed pipe.
  • TestSilentConnectionIsDroppedSoonAfterItsLastPongAck: a fake accesspoint end pings every 120 s and acknowledges each Pong for 10 minutes, during which the connection must stay open, then goes silent; the connection must be closed at most 140 s after its last PongAck. With the old ticker it fails with a silent connection was dropped 3m59s after its last PongAck, want at most 2m20s; with the margin set to -30 s, its live half fails, so it also guards against a bound tighter than the ping cadence.
• gofmt -l ., go vet -tags "test_unit test_integration" ./..., go build ./... and go test -count=1 -tags "test_unit test_integration" ./... are clean at each commit. Not run under -race: the race detector does not run on this kernel (arm64 with a 47-bit address space).

🤖 Generated with Claude Code