Employment Hero Queue
An in database async job queue with retries, exponential backoff, ordered channels and a dead letter state, no broker to run.
Store price is USD 113 all-in: installing this also pulls the 2 paid ERP Heritage modules it depends on.
Why this module
Employment Hero Queue
A queue without the moving parts
Jobs live in an ordinary Odoo model and drain on a scheduled action. There is no message broker, no separate worker fleet and no extra service to install, secure or monitor for light to medium volume.
Two drains never double run a job
The drain claims due jobs with SELECT FOR UPDATE SKIP LOCKED, so overlapping cron threads or worker processes step over each other's locked rows and each job runs exactly once. Proven across two real backend connections in the test suite.
Failures retry, then surface
A failed job retries on an exponential schedule up to its limit, then moves to a dead letter state instead of vanishing. A handler can be alerted on dead letter, and a reaper recovers jobs a crashed worker left running.
Day in the life
A bulk sync and a burst of webhook deliveries, handled out of band
A producer in the suite enqueues work: a bulk employee sync on a plain channel, and a run of webhook deliveries for one employee on an ordered channel so they apply in arrival order. The scheduled drain claims the due jobs under a row lock, runs them oldest first and commits each outcome as it lands, so one slow sync never holds up the others. A delivery that hits a transient error retries on exponential backoff while its ordered channel holds the line, so a later update for the same employee cannot overtake it. A genuinely broken job exhausts its retries, lands in Dead Letters with its full traceback, and notifies its handler model. You read the error, fix the cause and click Requeue. A long bulk sync keeps its claim fresh through a background heartbeat, so the reaper never mistakes it for a crashed worker.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
Two cron threads or worker processes draining at once never pick the same job. The claim uses SELECT FOR UPDATE SKIP LOCKED and commits the running flip before handlers run, so each job is taken exactly once. Verified across two real connections.
One failing job never aborts the drain. Each handler exception is captured on its own job and the drain continues, so a poison job in a batch cannot stop the good jobs from completing.
A failed attempt is rescheduled at min(60s times 2 to the attempt, 3600s) and the job goes back to the due set only once that time passes, so a struggling endpoint is not hammered.
Once attempts reach the configured limit the job moves to a dead letter state with its full traceback, kept for inspection and a one click requeue rather than being silently dropped.
An ordered channel runs its jobs strictly one at a time in arrival order. The head of line job holds the channel even while it sits in retry backoff, so a later same entity delivery (an update or a delete) can never overtake an earlier one that is mid retry.
A worker that dies mid handler leaves its job stuck in running. A reaper resets claims older than a configurable threshold back to failed, counting the lost run as an attempt, so the normal retry path picks it up and max retries still caps it.
A background heartbeat refreshes the job's claim on its own short lived database transaction while the handler runs, so the reaper never reclaims a bulk sync that is legitimately still in flight.
Run Now claims the job under a row lock first and skips any job a drain has already taken or that is already running, so a manual run can never double execute work.
Every job carries its company, and a record rule scopes the queue so users only see jobs for companies they belong to.
What is inside
Built to do the job, end to end.
- eh.queue.job model. The whole queue is one Odoo model: handler string, JSON payload, channel, state, attempts, max retries, run after time, last error traceback, company and claim timestamp. No broker, no external library, no schema you have to learn outside Odoo.
- Handler contract. A job names a handler as model.name:method and carries a JSON payload. The drain resolves the model, validates the method exists and calls it with the payload. A worked example handler ships in the model so producers have a template to follow.
- Scheduled drain and reaper. Two scheduled actions ship enabled: a drain that processes due jobs oldest first every few minutes, and a reaper that recovers jobs left running by a crashed worker. Both are ordinary Odoo cron records you can retune.
- Ordered channels. An opt in ordered flag on a channel makes its jobs run strictly one at a time in arrival order, so same entity work stays serialised. Plain channels keep claiming in parallel, so default throughput is unchanged.
- Dead letter view and actions. A filtered Dead Letters list shows jobs that exhausted their retries. From any job you can Run Now or Requeue, and the form shows the channel, attempts, run after time, payload and the full last error.
- Dead letter notification hook. When a job dead letters, the queue calls an optional _on_queue_dead_letter method on the handler model if it exists, so a poison delivery can raise an alert in the owning module rather than being silently parked.
- Tunable thresholds. Heartbeat interval and the stuck job threshold are read from system parameters, so you can tune crash recovery to the longest legitimate handler runtime without touching code.
- Automated tests. Fifteen tests cover enqueue defaults, drain success, retry to dead letter, requeue, failure isolation, the single cursor and true cross connection SKIP LOCKED claim, the reaper, run now safety, ordered channel serialisation including backoff, and the heartbeat against a real database cursor.
Honest about the edges
What this does not do, so nothing surprises you.
- This module is a generic in database job queue, not the integration engine itself. Field mapping, idempotent upsert against an external id, conflict resolution and append only sync audit live in the suite sync engine and connector modules, not here. This module runs the work; the handlers it calls do the integration.
- It is not a webhook receiver. Signature verification, replay protection and event routing belong to the suite webhook module. This queue can route webhook work to handlers, but it does no HMAC verification, dedupe or external id matching of its own.
- It does no API work directly: no OAuth token handling or refresh, no pagination and no rate limit handling. Those concerns belong to the handler methods a job calls and to the transport module.
- It is a database backed queue tuned for light to medium volume, not a high throughput message broker. Drain frequency and batch size are set by the cron, so very high sustained volumes are better served by a dedicated broker.
- Depends on eh_hero_sync (and through it the suite base), so it installs as part of the Employment Hero integration rather than as a standalone queue.
- Throughput is driven by the scheduled drain interval. Near real time processing means tightening the cron interval or triggering a drain on demand; the queue does not run a persistent always on worker.
Odoo job queue, Odoo async background jobs, in database queue Odoo, retry exponential backoff, dead letter queue Odoo, Odoo queue without broker, SELECT FOR UPDATE SKIP LOCKED, ordered channel queue, stuck job reaper, Employment Hero integration, Odoo 19 queue, multi company job queue, scheduled drain cron, idempotent retry, background sync queue
Need this fitted to the way you work?
ERP Heritage delivers end to end Odoo work: Odoo Implementation, Customization and Development, Integration, Migration, Consultation, Support and Training. We help teams put this module into production, shape it to their process, and keep it running.
We work with businesses across Australia (Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra) and the Middle East (Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Muscat). Start a conversation at erpheritage.com.au or email info@erpheritage.com.au.
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
Bring Employment Hero onboarding workflows, employee goals and contractor flags into Odoo Community as real recor...
Sync attendance clock events from the Employment Hero people platform into the stock Odoo Attendances app, keyed...
The Singapore country pack for the ERP Heritage Employment Hero integration
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
Discuss (mail)
|
| Community Apps Dependencies | Show |
| Lines of code | 3969 |
| Technical Name |
eh_hero_queue |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module