The writeup contains two timeouts, set at very different limits. The anti-pattern version calls requests.post with timeout=30 inside action_post, holding an Odoo WSGI worker for up to half a minute per posted invoice, and losing the invoice rollback if the Kenya Revenue Authority drops the connection [6]. The shipped module caps the inline attempt at 4 seconds [8]. That is 4/30 of the worker hold, near 13 percent [20], and it is the only piece of the fiscalisation path you can size a worker pool against.
The same post says KRA endpoints often take several seconds to answer during peak filing deadlines [7]. Set the inline budget below the observed response time and the retry queue stops being an exception handler. It carries ordinary traffic in exactly the week volumes peak. The cron interval, not the KRA endpoint, then decides how soon a customer's receipt gets its control code.
The ladder is arithmetic you can run. Each failure sets the next wait to (2 ** retry_count) * 15 seconds plus 1 to 10 seconds of jitter [14], and a retry_count above 8 marks the row permanently failed [13]. That allows nine cron attempts [18]. Eight waits at 15 times 2, 4, 8, 16, 32, 64, 128 and 256 sum to 7,650 seconds, or 2 hours 7 minutes 30 seconds, plus 8 to 80 seconds of jitter [19]. Treat it as a floor. The clock only advances when the cron fires, and the writeup does not state the sweep frequency [21].
The indexing on the queue model reflects careful work. state and next_retry_time both carry index=True, and the sweep domain queries exactly those two columns with limit=50 [11][12]. Two small things read differently. move_id is declared ondelete="cascade" [11], so the queue is coupled to the document lifecycle rather than standing as an independent log of transmission attempts. And the prose says a failed call marks the record pending_retry [10], which is not one of the four values in the Selection [11]. Naming drift in a blog post is cheap; naming drift between the narrative and the state machine is where an ops runbook goes wrong.
The important gap here is a legal one. The post opens by stating that a POS knocked offline by a fiber cut cannot lawfully issue receipts [3], and it ends the eTIMS section saying the QR code and Control Unit ID render on QWeb PDFs and OWL thermal receipts [15]. What a thermal printer emits while the queue row is still pending is not shown [22]. Deferred signing is the right shape for the worker pool. Whether it is the right shape for a KRA audit depends on that unprinted receipt.
On the payment side, the writeup runs out. It describes STK Push from the till and unsolicited C2B payments to a Paybill or Till number [16], in a market it puts at over 80 percent of commercial transactions settling through M-Pesa [2], and confirms Safaricom sends validation and confirmation callbacks over HTTPS [17]. The text then breaks off mid-sentence on the network hops between Safaricom and the customer instance [17]. Reconciliation of duplicate or late confirmations, the half that decides whether the accounting team keeps typing, is not in the published portion.
