Employment Hero Queue
A dependency-free async job queue with retries, backoff, and a dead-letter safety net.
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
Retries, then a safety net
Handler failures retry with exponential backoff (60s base, 3600s ceiling) up to a configurable max. When attempts are exhausted the job parks in a dead-letter state with its full traceback, so a poison delivery is held for inspection, not silently dropped. One failing job never aborts the drain of the rest.
No job runs twice
The drain claims due jobs with SELECT FOR UPDATE SKIP LOCKED, so two concurrent drains step over each other's locked rows and can never double-run a job. A cross-cursor test proves the disjoint claim. Opt-in ordered channels serialise same-entity work in arrival order, including holding the head-of-line job through its retry backoff.
Nothing external to run
A dependency-free queue that drains on a schedule and can be run on demand from the form. No third-party broker, no extra process to babysit. A reaper cron recovers jobs left running by a crashed worker, and a background heartbeat keeps genuinely in-flight long syncs from being reclaimed.
Day in the life
A webhook burst lands during payroll close
A flurry of deliveries for the same employee arrives while the team is mid close. Each is enqueued on a per-entity ordered channel, so the create, the update, and the delete run strictly in order, never concurrently, and never overtaking one another. One delivery references a record that is briefly locked and raises; it backs off and retries instead of failing the batch, and because it is the head of its ordered channel it holds that channel until it resolves rather than letting a later update jump ahead. The rest of the queue drains normally. A delivery that keeps failing exhausts its retries, lands in Dead Letters with its traceback, and the handler model surfaces it. After close, an operator opens the dead letter, reads the error, fixes the cause, and clicks Requeue to run it again from scratch.
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 drain threads or worker processes run at once. SELECT FOR UPDATE SKIP LOCKED makes each step over the rows the other holds, so a job is claimed exactly once. Proven by a two-cursor test on committed rows.
A worker dies mid-handler, leaving a row stuck in running. A reaper cron resets claims older than a configurable threshold (default 30 minutes) back to failed, counting the lost run as an attempt so max_retries still caps it.
A legitimate bulk sync runs past the stuck threshold. A background heartbeat refreshes claimed_at on its own autonomous cursor while the handler runs, so the reaper never reclaims a job that is genuinely still working.
The head delivery on an ordered channel fails and is waiting out its backoff with a future eta. Later same-channel deliveries are held, tested by arrival id not eta, so an update or delete can never overtake a mid-retry head and corrupt ordering.
A job whose handler always raises, or names an unknown model or missing method, is dead-lettered rather than aborting the drain. The handler model can implement _on_queue_dead_letter to alert; any failure to alert is logged and never breaks the queue.
An operator clicks Run Now on a job a drain has already taken. Run-now claims under a row lock first and skips a row that is already running, so a manual run cannot double-execute a claimed job.
Every job carries a company, and a global record rule scopes the queue to the companies in the user's allowed set, with company-less jobs always visible.
What is inside
Built to do the job, end to end.
- Job model and handler contract. eh.queue.job stores channel, handler (model.name:method), JSON payload, state, attempts, max_retries, eta, last error, company, and claim timestamp. enqueue() creates a queued job; the drain resolves and validates the handler, calls it with the payload, and records done, failed, or dead.
- Backoff and dead-letter logic. On failure, attempts increments and the full traceback is captured. Below max_retries the job is set failed with eta pushed out by min(60 * 2^attempts, 3600) seconds. At the limit it becomes a dead letter and notifies the handler model via _on_queue_dead_letter when implemented.
- Atomic claim and ordered channels. _claim_due uses SELECT FOR UPDATE SKIP LOCKED, flips claimed rows to running, flushes, and commits the claim off the queue. Ordered channels add a same-channel running check and an earlier-arriving-pending check so one entity's jobs serialise.
- Drain and reaper crons. A scheduled drain runs due queued and failed jobs oldest eta first, committing each outcome as it lands; it can also be run on demand from the form. A separate reaper cron recovers jobs left running past the stuck threshold back into the retry path.
- Operator views and actions. List, form, and search views with state badges, a Due Now filter, and grouping by state and channel. A dedicated Dead Letters view filters exhausted jobs. Run Now and Requeue buttons let managers re-run or reset jobs from the UI.
- Security and scoping. Suite users get read access; suite managers get full write, create, and unlink. A global company-isolation record rule keeps each company to its own jobs. Tuning parameters (heartbeat seconds, stuck minutes) read from ir.config_parameter.
Honest about the edges
What this does not do, so nothing surprises you.
- This is the execution engine only. It does not receive webhooks or map fields; the webhook module enqueues onto it. It runs whatever handler a job names.
- The drain runs on Odoo's scheduler (default every 10 minutes) and on demand from the form. It is not a sub-second real-time worker; latency is bounded by the cron interval unless you run a job manually.
- There is no two-way sync, conflict resolution, or field mapping in this module. Those concerns live in the handler and in other suite modules; the queue only delivers the payload and records the outcome.
- Concurrency safety relies on PostgreSQL row locks (FOR UPDATE SKIP LOCKED). It targets a PostgreSQL-backed Odoo deployment.
- Requires the Employment Hero sync foundation module and is built for Odoo 18 Community. It is not a general standalone task scheduler sold on its own.
Odoo 18 job queue, Employment Hero queue, async task runner Odoo, retry exponential backoff Odoo, dead letter queue Odoo, SELECT FOR UPDATE SKIP LOCKED, background jobs Odoo Community, webhook processing queue, ordered channel queue, stuck job reaper, multi-company job queue, dependency free Odoo 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 | 3955 |
| 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