Page MenuHomePhabricator

[tunnelbroker] Trigger AMQP reconnect when closing session
Needs ReviewPublic

Authored by bartek on Thu, Oct 3, 1:37 PM.
Tags
None
Referenced Files
F2889899: D13607.id.diff
Fri, Oct 4, 7:34 AM
F2888816: D13607.id44895.diff
Fri, Oct 4, 5:47 AM
F2888815: D13607.id44887.diff
Fri, Oct 4, 5:47 AM
F2888784: D13607.id.diff
Fri, Oct 4, 5:46 AM
F2888773: D13607.diff
Fri, Oct 4, 5:46 AM
F2887560: D13607.id.diff
Fri, Oct 4, 3:09 AM
F2887192: D13607.id44887.diff
Fri, Oct 4, 1:51 AM
F2885880: D13607.diff
Thu, Oct 3, 8:50 PM
Subscribers

Details

Reviewers
kamil
varun
will
Summary

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

Test Plan

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

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

bartek held this revision as a draft.
bartek edited the test plan for this revision. (Show Details)
bartek published this revision for review.Fri, Oct 4, 8:44 AM
bartek added inline comments.
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