Most of errors were happening here. WS session was closed so consumer cancelation and queue removal calls weren't able to succeed.
Depends on D13606
Details
Details
Observing logs on staging. Possible but hard to reproduce with commtest
Can also be reproduced by:
- Connecting a device to healthy Tunnelbroker
- Don't make any traffic
- Disconnect RabbitMQ
- Then disconnect device
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/tunnelbroker/src/websockets/session.rs | ||
|---|---|---|
| 743–747 | According to RabbitMQ docs, if the channel is closed, all its consumers are also closed, so instead of recovering here, we can simply ensure connection is okay and exit early | |
| 757–762 | This is to avoid spamming error alerts while connection errors are handled by our code elsewhere | |
| 766–771 | We can probably consider having a separate task for cleaning up queues in case they're not able to be properly deleted here | |