Blog Quarkus Insights #264: JobRunr 9 on Quarkus 3.40 LTS: What Happens When a Job Fails Halfway?

October 19, 2026 #quarkus-insights

Quarkus Insights #264: JobRunr 9 on Quarkus 3.40 LTS: What Happens When a Job Fails Halfway?

James Cobb avatar James Cobb

This summary was generated using AI, reviewed by humans - watch the video for the full story.

Quarkus Insights #264: JobRunr 9 on Quarkus 3.40 LTS: What Happens When a Job Fails Halfway?

Background job processing is essential for modern web applications, yet handling long-running distributed tasks reliably remains a persistent challenge. What happens when a multi-step job bills a customer, generates an invoice, and crashes while sending an email? In episode 264, Ronald Dehuysser, creator and founder of JobRunr, joins hosts Eric Deandrea and Holly Cummins to celebrate the release of JobRunr 9 and its day-one alignment with Quarkus 3.40 LTS. Through live coding and architectural discussion, Ronald demonstrates how JobRunr simplifies distributed processing in Java, schedules background tasks around clean energy grid forecasts, and guarantees step-level idempotency so failed jobs can safely retry without duplicating side effects.

Quarkus Ecosystem News

Holly kicked off the episode with updates across the Quarkus ecosystem:

Origins and Architecture of JobRunr

Ronald shared the backstory behind JobRunr. While freelancing prior to the pandemic, he faced distributed computing challenges in Java where background tasks lacked consistent correlation IDs, jobs vanished into dead-letter queues without monitoring, and debugging required parsing disjointed logs.

Frustrated by the lack of developer-friendly tooling, Ronald spent eight months building JobRunr from the ground up. To make the project commercially sustainable, he introduced a Pro tier alongside the open source core, which has since grown into a full-time business supporting a dedicated five-person team.

Architecturally, JobRunr allows developers to enqueue standard Java 8+ lambdas directly from their services or REST endpoints. Rather than executing heavy tasks synchronously on the frontend server, JobRunr serializes the invocation and persists it immediately into a shared database (such as PostgreSQL). Dedicated background worker nodes continuously poll the database, lock pending jobs, and execute the work asynchronously. This design keeps web endpoints fast and lightweight while allowing background processing nodes to scale independently on container platforms like Red Hat OpenShift.

Aligning JobRunr 9 with Quarkus 3.40 LTS

The timing of episode 264 coincides with two major release milestones: JobRunr 9 and Quarkus 3.40 LTS. Ronald explained that the JobRunr team prioritizes supporting every Quarkus LTS stream on release day. When Quarkus 3.40 was announced, the team synchronized their release cadence to ensure seamless, immediate compatibility.

The hosts and Ronald discussed the realities of managing release trains, balancing tight deadlines, and coordinating multi-project dependencies when downstream releases depend on upstream release candidates.

Live Demo: Setting Up JobRunr in Quarkus

Ronald demonstrated building a JobRunr-backed Quarkus application live in IntelliJ IDEA using Quarkus 3.40.1 and Gradle.

Key aspects of the setup included:

  1. Database configuration: Connecting to a central PostgreSQL database instance as JobRunr’s source of truth for job persistence and distributed locking.

  2. Quarkus JobRunr extension: Adding the extension dependency, which automatically configures and exposes the JobScheduler as an injectable CDI bean.

  3. Constructor injection: Injecting both application business services and JobScheduler into a Jakarta REST resource.

  4. Enqueuing jobs via lambdas: Triggering background execution with jobScheduler.enqueue) → myService.myBusinessMethod(input.

  5. Configuration flags: Enabling background job processing and the JobRunr web dashboard through configuration properties (which can be toggled via environment variables across deployment environments).

  6. Live reload in dev mode: Demonstrating Quarkus dev mode by fixing an incorrect REST annotation on the fly and immediately retesting without restarting the application or losing state.

Carbon-Aware Job Scheduling

Both Holly and Ronald share a passion for green software engineering and sustainability. In JobRunr, Ronald introduced carbon-aware scheduling to help developers minimize the environmental impact of their compute workloads.

When scheduling batch jobs, developers often do not need immediate execution as long as the task completes before a specific deadline. With carbon-aware scheduling, developers specify their geographic location (such as Belgium) and a target execution window (for example, between now and four hours from now).

Behind the scenes, JobRunr evaluates real-time energy grid data and forecasts:

  • Grid intensity forecasting: In Europe, JobRunr connects to the ENTSO-E (European Network of Transmission System Operators for Electricity) API to forecast when grid carbon emissions are lowest due to renewable generation (wind and solar).

  • North American grid support: Because United States power grids are fragmented across regional operators, JobRunr partnered with Electricity Maps to provide grid carbon intensity forecasts across North America.

  • Fallback behavior: If grid forecasting APIs become unavailable, JobRunr safely schedules the job at the end of the requested window to maximize the chance of acquiring fresh grid data before executing.

  • Real-world adoption: Enterprise users such as sports retailer Decathlon utilize carbon-aware scheduling to process batch data during low-emission hours while guaranteeing completion before retail stores open each morning.

The JobRunr dashboard provides visual graphs mapping diurnal grid patterns, identifying solar peaks, morning coffee surges, and optimal low-carbon execution windows.

Handling Job Failures Halfway: Step-Level Idempotency with JobContext

The central focus of JobRunr 9 is addressing what happens when a complex, multi-step job fails partway through execution.

Consider an e-commerce order fulfillment workflow:

  1. Charge the customer credit card via Stripe.

  2. Generate an invoice PDF document.

  3. Send the invoice email via SendGrid.

By default, JobRunr automatically retries failed jobs up to 10 times using exponential backoff. If the third step fails (for example, if SendGrid experiences a temporary outage), a naive retry executes the entire method again from the beginning. This risks charging the customer multiple times for the same order.

To solve this problem, JobRunr 9 introduces JobContext and the runStepOnce(…​) construct:

  • Step recording: Each distinct phase of the job is wrapped in a jobContext.runStepOnce(…​) block.

  • Automatic step skipping: When a step succeeds, JobRunr records its completion in the job’s state metadata.

  • Safe retries: If a subsequent step throws an exception, JobRunr retries only the failed step and any remaining steps. Previously completed steps (such as the payment processing and invoice generation) are automatically skipped.

  • Timeline visualization: The JobRunr dashboard renders a real-time visual timeline of the job execution, marking completed steps in green, failed steps in red, and skipped steps clearly during retries.

Open Source vs. Pro and Workflow Orchestration

Ronald clarified the differences between the open source and commercial Pro editions of JobRunr:

  • Open Source: Fully featured distributed background processing, automatic retries with exponential backoff, database-backed job storage, carbon-aware scheduling, and the embedded web dashboard.

  • Pro Tier: Designed for high-scale enterprise workloads, adding priority queues, multi-tenancy, batch job chaining (allowing a parent job to spawn millions of child jobs and trigger follow-up jobs only upon overall success), complex workflow state machines, and human-in-the-loop approval workflows suitable for agentic AI architectures.

Looking Ahead to Quarkus 4

The episode concluded with a preview of upcoming architectural updates in Quarkus 4:

  • Core component upgrades: Quarkus 4 brings major upgrades across fundamental dependencies, including Netty, Eclipse Vert.x 5, Hibernate 8, and Jackson 3.

  • Java 21 baseline: Quarkus 4 establishes Java 21 as the minimum baseline, unlocking deep optimizations for virtual threads throughout the framework.

  • Virtual thread throughput: Ronald noted that running JobRunr workloads on virtual threads nearly doubles job processing throughput compared to platform threads by efficiently yielding during database queries and outbound HTTP network calls.

Key Takeaways

  1. JobRunr simplifies distributed Java jobs: Enqueue background tasks with standard Java lambdas without managing message queues or complex serialization.

  2. Quarkus 3.40 LTS alignment: JobRunr 9 was released in lockstep with Quarkus 3.40 LTS for day-one compatibility.

  3. CDI and dev mode integration: The Quarkus JobRunr extension injects JobScheduler into CDI beans and supports Quarkus dev mode live coding out of the box.

  4. Carbon-aware scheduling: Schedule non-urgent jobs to run when energy grid carbon intensity is lowest, utilizing ENTSO-E in Europe and Electricity Maps in North America.

  5. Default automatic retries: JobRunr automatically retries failed jobs up to 10 times with exponential backoff.

  6. The risk of partial failure: Retrying multi-step jobs without safeguards can cause unintended side effects, such as duplicate credit card charges.

  7. Step-level idempotency with runStepOnce: JobRunr 9’s JobContext records completed steps and skips them on retry, ensuring safe recovery from midway failures.

  8. Real-time dashboard: The built-in dashboard visualizes job queues, execution timelines, step statuses, and grid carbon intensity graphs.

  9. Advanced workflows in JobRunr Pro: Enterprise capabilities include multi-tenancy, priority queues, batch job fan-out, and human-in-the-loop workflows.

  10. Quarkus 4 and virtual threads: Upgrading to the Java 21 baseline in Quarkus 4 delivers significant throughput gains for I/O-intensive background jobs running on virtual threads.

Conclusion

Background job reliability requires more than just automatic retries; it demands precise visibility and safe recovery mechanisms when things go wrong halfway through execution. JobRunr 9 delivers on this promise by combining developer-friendly lambda scheduling with JobContext step-level idempotency, real-time dashboard observability, and innovative carbon-aware scheduling. With first-class Quarkus extension integration, developers on Quarkus 3.40 LTS can offload heavy processing to background workers with complete confidence. Next week, Quarkus Insights returns with Eric Deandrea presenting LLM evaluation and observability using Langfuse.

Watch the full episode on the Quarkus YouTube channel and explore JobRunr documentation at jobrunr.io.

Quarkus is open. All dependencies of this project are available under the Apache Software License 2.0 or compatible license. CC by 3.0

This website was built with Roq on Quarkus, is hosted on GitHub Pages and is completely open source. If you want to make it better, fork the website and show us what you’ve got.

Navigation
Follow Us
Get Help
Languages
Quarkus is made of community projects
Copyright © Quarkus. All rights reserved. For details on our trademarks, please visit our Trademark Policy and Trademark List. Trademarks of third parties are owned by their respective holders and their mention here does not suggest any endorsement or association.