Claiming a sidecar ticket a second time gives unexpected behavior

I claimed a sidecar ticket on 1 pool daemon. Then I tried to claim it again on a second daemon. From the CLI it seemed to take it just fine (it returned back an encoded ticket). But in the logs it was rapidly repeating these logs:

2021-10-08 13:32:23.677 [INF] POOL: Receive new message for ticket (id=8920bdc863ee35f9) via stream_id=b0d7573369fd0cdc531de0543a91acfbef9802a24f34434fd09f206d0caa045b5bcf1af08315a5b985f7c6b09deb0c3fa5b8be73fdfb56fad69b669b16297cb0, provider=false
2021-10-08 13:32:23.677 [INF] POOL: Waiting for ticket (id=8920bdc863ee35f9) using stream_id=b0d7573369fd0cdc531de0543a91acfbef9802a24f34434fd09f206d0caa045b5bcf1af08315a5b985f7c6b09deb0c3fa5b8be73fdfb56fad69b669b16297cb0, provider=false
2021-10-08 13:32:24.395 [INF] POOL: Waiting for ticket (id=8920bdc863ee35f9) using stream_id=b0d7573369fd0cdc531de0543a91acfbef9802a24f34434fd09f206d0caa045b5bcf1af08315a5b985f7c6b09deb0c3fa5b8be73fdfb56fad69b669b16297cb0, provider=false
2021-10-08 13:32:24.396 [ERR] POOL: unable to transition state: failed to expect channel: sidecar with order nonce 02395e7fa79ba7cc17324a4b05bae82800a2439d013ea920add24c02f4c8e1f7 is already registered
2021-10-08 13:32:24.596 [INF] POOL: Receive new message for ticket (id=8920bdc863ee35f9) via stream_id=b0d7573369fd0cdc531de0543a91acfbef9802a24f34434fd09f206d0caa045b5bcf1af08315a5b985f7c6b09deb0c3fa5b8be73fdfb56fad69b669b16297cb0, provider=false
2021-10-08 13:32:24.597 [INF] POOL: Waiting for ticket (id=8920bdc863ee35f9) using stream_id=b0d7573369fd0cdc531de0543a91acfbef9802a24f34434fd09f206d0caa045b5bcf1af08315a5b985f7c6b09deb0c3fa5b8be73fdfb56fad69b669b16297cb0, provider=false
2021-10-08 13:32:24.597 [ERR] POOL: unable to transition state: failed to expect channel: sidecar with order nonce 02395e7fa79ba7cc17324a4b05bae82800a2439d013ea920add24c02f4c8e1f7 is already registered

Expected behavior

I expect when I used the CLI to register a sidecar ticket that has already been claimed, it returns an error so it's obvious it didn't work. Then the pool daemon shouldn't keep trying to register the ticket.

Actual behavior

CLI appears to work fine (even though it doesn't) and poold keeps trying to redeem the ticket.

To reproduce

• Create a sidecar ticket
• claim it on Poold A
• claim it again on Poold B

System information

macOS
master branch (poold version 0.5.1-alpha commit=v0.5.1-alpha-24-g9e5e1a8c52afa977e8f6b2e184b7ed0a6739f0a7)
LND 0.13.3

Start with the CLI sidecar-ticket claim flow and the pool daemon's ticket redemption and state-transition paths. Reproduce the two-daemon sequence from the issue, then trace how the already-registered sidecar error is returned and handled. Done means the CLI reports the failed second claim and the pool daemon stops retrying it.