Page MenuHomePhabricator

[tunnelbroker] Trigger AMQP reconnect when closing session
ClosedPublic

Authored by bartek on Oct 3 2024, 1:37 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 18, 11:38 AM
Unknown Object (File)
Wed, Dec 18, 11:38 AM
Unknown Object (File)
Wed, Dec 18, 11:38 AM
Unknown Object (File)
Wed, Dec 18, 11:38 AM
Unknown Object (File)
Mon, Nov 25, 1:14 PM
Unknown Object (File)
Fri, Nov 22, 4:48 PM
Unknown Object (File)
Fri, Nov 22, 4:48 PM
Unknown Object (File)
Fri, Nov 22, 4:48 PM
Subscribers

Details

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
Lint Not Applicable
Unit
Tests Not Applicable

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.Oct 4 2024, 8:44 AM
bartek added inline comments.
services/tunnelbroker/src/websockets/session.rs
743–747 ↗(On Diff #44904)

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 ↗(On Diff #44904)

This is to avoid spamming error alerts while connection errors are handled by our code elsewhere

766–771 ↗(On Diff #44904)

We can probably consider having a separate task for cleaning up queues in case they're not able to be properly deleted here

kamil added inline comments.
services/tunnelbroker/src/websockets/session.rs
743–747 ↗(On Diff #44904)

good idea to ensure connection is okay

766–771 ↗(On Diff #44904)

This seems reasonable

This revision is now accepted and ready to land.Oct 7 2024, 2:22 AM