Preserving Dave's comment here:
I'm not convinced the problematic ones will stay in the queue. Having failed the INSERT, and logged the error, we just continue onto basic_ack() the message, which should remove the message from queue storage and reply to the client that we've successfully dealt with their message. In fact, crashing out here would preserve the message because we *wouldn't* ack it. You could choose to only ack those messages that we successfully INSERT, which should preserve the ones that fail (assuming that's not a violation of the AMQP protocol -- it's not one I'm overly familiar with). But consider the likely INSERT failure scenarios. If it starts failing, it likely won't be a case of "some succeed and some fail"; it'll be something like the database has become inaccessible (due to storage failure) or the database has changed to an incompatible structure. In either case we can pretty much expect all future INSERTs to fail, so whether we crash out with the relevant error, or just start log spamming tons of failures to the log, the effect on the incoming queue would be the same: it builds and builds until either someone fixes stuff or it runs out of storage. -- https://code.launchpad.net/~andersson123/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/460847 Your team Canonical's Ubuntu QA is requested to review the proposed merge of ~andersson123/autopkgtest-cloud:d-r-d-a-r-merging into autopkgtest-cloud:master. -- Mailing list: https://launchpad.net/~canonical-ubuntu-qa Post to : canonical-ubuntu-qa@lists.launchpad.net Unsubscribe : https://launchpad.net/~canonical-ubuntu-qa More help : https://help.launchpad.net/ListHelp
