Employment Hero Queue
An in-database async job queue with retries, exponential backoff and a dead letter state, no external broker required.
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
Async work without the ops cost
Jobs live in an ordinary model that drains on a schedule, so there is no message broker or worker fleet to install, secure or monitor for light to medium volume.
Failures retry, then surface
A failing handler is retried on an exponential schedule up to a configurable limit, then moved to a dead letter state for review instead of vanishing or hammering a struggling endpoint.
Never double runs a job
Due jobs are claimed with a row lock that skips rows another worker holds, so two overlapping drains claim disjoint sets and the same job is never executed twice.
Day in the life
A burst of webhook deliveries lands during a sync
An external change fires several webhook deliveries while a bulk sync is already running. The controller enqueues each delivery as a job rather than processing it inline, so the HTTP response returns at once. The scheduled drain claims the due jobs under a row lock and runs them out of band. One delivery hits a transient endpoint error; it retries on an exponential schedule rather than failing the batch, while its siblings complete. Deliveries for the same record run on an ordered channel, so an update never overtakes the create that precedes it. A job that exhausts every retry lands in the dead letter view, where you read the captured traceback and requeue it once the cause is fixed.
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 overlapping drains never pick the same job: the claim uses SELECT FOR UPDATE SKIP LOCKED and commits the running state before handlers run, proven by a cross-connection test that claims disjoint sets.
A worker that dies mid-handler leaves a row stuck in running forever. A scheduled reaper resets claims older than a configurable threshold back to failed so the normal retry path picks them up.
A background heartbeat refreshes the claim timestamp on its own autonomous cursor while a long handler runs, so the reaper never reclaims a job that is legitimately still working.
A failing job is captured on its own row and the drain continues with the next; one poison item never aborts the rest of the batch.
A job that exhausts its retries is dead lettered, and the queue calls an optional hook on the handler model so the failure can be surfaced rather than silently dropped.
On an ordered channel a head job that is mid-retry with a future eta holds the channel, so a later same-entity delivery cannot overtake an earlier one that has not yet succeeded.
A malformed or unknown handler string fails resolution cleanly every attempt and dead letters instead of raising into the drain loop.
Run Now claims the row under a lock first and skips a job a drain has already taken, so a manual run cannot double execute a job that is already running.
Each job carries a company and a global record rule scopes the queue per company, so jobs are visible only within their company allowance.
What is inside
Built to do the job, end to end.
- The job model. eh.queue.job stores the handler, JSON payload, channel, state, attempts, max retries, run-after eta, last error and claim timestamp. States are queued, running, done, failed and dead letter.
- Enqueue and handler contract. Producers call enqueue with a handler in the form model.name:method, a payload, an optional channel and eta, a retry limit and an ordered flag. The drain resolves and validates the model and method before calling it.
- Drain and reaper crons. One scheduled action drains due jobs oldest eta first, claiming them under a row lock and committing each outcome as it happens. A second scheduled action reaps jobs left running past the stuck threshold.
- Retry and dead letter. On failure the attempt count rises and the job is rescheduled with exponential backoff up to a ceiling, or dead lettered once the retry limit is reached. An optional handler hook is called on dead letter.
- Views and actions. List, form and search views expose every state with colour coding, a dead-letter filtered view and menu, a Run Now button and a Requeue action that resets a job from scratch.
- Tuning and scope. Heartbeat interval and stuck threshold are configuration parameters. A global company record rule scopes jobs per company, and access is split between a read-only user group and a manage group.
Honest about the edges
What this does not do, so nothing surprises you.
- This is a generic job runner, not a sync engine. It executes whatever handler it is given and does no field mapping, upsert, conflict resolution or two-way sync itself; that logic lives in the modules whose handlers it calls.
- It does not verify, sign or route webhooks. The webhook module owns signature checks and replay protection and simply enqueues work here.
- Draining is driven by a scheduled action, so latency is bounded by the cron interval rather than being truly instant. Jobs can also be run on demand from the form.
- Concurrency safety relies on PostgreSQL row locking (SELECT FOR UPDATE SKIP LOCKED); the queue targets PostgreSQL as Odoo ships it.
- The reaper threshold must exceed the longest legitimate handler runtime so genuinely in-flight jobs are never reclaimed; tune it for your slowest job.
- It is sized for light to medium volume that fits comfortably in the database. Very high throughput streaming workloads are better served by a dedicated broker.
- It depends on eh_hero_sync and the wider Employment Hero suite for the connection and handler models that produce jobs.
Odoo async job queue, Odoo background jobs, in-database queue no broker, retry with exponential backoff, dead letter queue Odoo, SELECT FOR UPDATE SKIP LOCKED, scheduled cron drain, concurrency safe worker, webhook job queue, bulk sync background processing, Employment Hero integration, Odoo 16 Community queue, stuck job reaper, per-entity ordered queue, job retry and dead letter
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 | 3916 |
| 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