[VOTR-185] autodelete component queues

[zachschubert]

This PR reverts the changes in #86, which don't seem to be working as intended. That change was recently installed by the routes-generator staging consumers, which have since begun consistently falling into a connection error loop. Meanwhile, the broker is reporting hundreds of consumer bindings on their component queue. I don't have a theory for the reverted change could be failing, but I don't see any other commits that could account for it.

I also added the auto-delete flag to the component queue declaration, which should have the same effect.

[anttimoelsae]

This PR reverts the changes in #86, which don't seem to be working as intended. That change was recently installed by the routes-generator staging consumers, which have since begun consistently falling into a connection error loop. Meanwhile, the broker is reporting hundreds of consumer bindings on their component queue. I don't have a theory for the reverted change could be failing, but I don't see any other commits that could account for it.

I also added the auto-delete flag to the component queue declaration, which should have the same effect.

You saw this only in staging, not in QA? I suppose in that case there is some unpredictable behavior and we have to scrap this strategy.

The goal was to remove "straggler" bindings in the case that the subtopic of the component is changed. I.e. we deploy a new version, a new binding is added to the queue, but the binding from the previous deployment does not get removed. In this case the queue would never reach 0 consumers, which is when auto-delete would delete the queue.

[zachschubert]

You saw this only in staging, not in QA? I suppose in that case there is some unpredictable behavior and we have to scrap this strategy.

That's right, I never saw it in QA. It's hard to guess why ¯\(ツ)/¯

The goal was to remove "straggler" bindings in the case that the subtopic of the component is changed. I.e. we deploy a new version, a new binding is added to the queue, but the binding from the previous deployment does not get removed. In this case the queue would never reach 0 consumers, which is when auto-delete would delete the queue.

The broker will also autodelete the queue when all consumers have closed their connections, which would happen after a successful deploy that changes that subtopic. I confirmed that this is the case by testing manually.

[codecov-commenter]

Codecov Report

Merging #94 (a221542) into master (dd2e1d4) will increase coverage by 0.09%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master      #94      +/-   ##
==========================================
+ Coverage   68.43%   68.53%   +0.09%     
==========================================
  Files          33       33              
  Lines        1467     1465       -2     
==========================================
  Hits         1004     1004              
+ Misses        463      461       -2     

Impacted Files	Coverage Δ
ergo/amqp_invoker.py	31.19% <0.00%> (+0.56%)	⬆️
ergo/version.py	33.33% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.