# Trace a runtime bug from a stack trace in Quarkus with Atlas in 2026 > Atlas helps Quarkus developers quickly trace runtime bugs from production stack traces to a fix, integrating with Maven and JUnit 5. Atlas empowers Quarkus developers in 2026 to trace runtime bugs from production stack traces directly to the responsible line of code and apply a fix, all without attaching a debugger. It integrates direct with your existing Quarkus toolchain, including Maven for dependency management, JUnit 5 for testing, and Spotless for code formatting, streamlining the entire debugging and remediation process. ## Key takeaways - Atlas precisely traces Quarkus runtime bugs using `file:line` offsets and AST indexing. - Leverage Atlas's `grep` and `lsp` tools to find the true origin of Quarkus exceptions. - Fix Quarkus code and add `@QuarkusTest` regression tests with Atlas's `edit` tool. - Atlas integrates with `Maven` and `Spotless` for a complete Quarkus development workflow. - All Quarkus code changes are permission-gated and require explicit developer approval via unified diffs. ## How Atlas Reads a Quarkus Stack Trace for Bug Triage Atlas begins tracing a Quarkus runtime bug by consuming the raw stack trace, reading each file:line pair at its reported offset. This process ensures that even a complex trace with 10 or more frames is accurately interpreted against your current codebase, preventing misdirection from outdated line numbers. Atlas's `read` tool is the first step in diagnosing a Quarkus runtime bug. When you paste a production stack trace, Atlas processes each `file:line` entry. It uses its AST-based indexing, built with tree-sitter, to precisely locate the code at the specified offset within your Quarkus project. This is crucial for Quarkus applications, where build-time augmentation can sometimes shift line numbers in compiled code. Atlas validates the reported offset against the current file content. If the `read` tool reports "Offset is out of range for this file," it's a clear signal that the stack trace originated from a different build. In such cases, Atlas will prompt you to re-read the file from the top, ensuring that any subsequent analysis is based on the correct code context. This robust validation prevents Atlas from pointing to the wrong code, a common pitfall when debugging production issues with potentially mismatched binaries. Atlas operates within your `pom.xml`-defined project, understanding the project structure and dependencies, which is essential for navigating complex Quarkus module layouts. ## Pinpointing Quarkus Error Origins with Grep and LSP After reading the stack trace, Atlas leverages its `grep` and `lsp` tools to pinpoint the exact origin of a Quarkus runtime error, often revealing more than the top frame alone. This dual approach helps identify the precise line where an error message is constructed, even across 2 or more layers of abstraction in your CDI beans or JAX-RS resources. Once the stack trace frames are validated, Atlas moves beyond the immediate failure point to uncover the root cause. The `grep` tool is employed to search for the specific error message string found in the stack trace. This often leads to the location where the error message is constructed, which can be far more informative than just the top-most frame of the exception. For Quarkus applications, where exceptions might originate deep within framework-generated code or specific CDI bean lifecycles, finding the message construction point is invaluable. Following this, Atlas utilizes its `lsp` (Language Server Protocol) tool, specifically the `findReferences` operation, on the failing function identified in the trace. This allows Atlas to identify all callers that can reach the problematic function with the bad input, providing a comprehensive view of the call graph. This is particularly effective in Quarkus, where dependency injection and JAX-RS resource methods can have multiple entry points, and understanding the flow of data through these components is critical for debugging. Atlas's ability to index code by AST declarations, rather than blind line windows, ensures that `lsp` queries are highly accurate, even in the presence of Quarkus's build-time bytecode transformations. ## Applying Quarkus Fixes and Adding Regression Tests Atlas facilitates fixing Quarkus runtime bugs by allowing you to `edit` the code directly and then immediately add a robust regression test using `JUnit 5 (@QuarkusTest)`. This ensures that once a bug is resolved, it cannot silently recur, providing a 100% verifiable solution within your existing Maven build process. With the root cause identified, Atlas transitions to the remediation phase using its `edit` tool. You can instruct Atlas to modify the problematic code directly. After applying the fix, a critical step in the workflow is to add a regression test. Atlas can assist in generating `@QuarkusTest` cases, leveraging `RestAssured` for integration testing, which is standard practice in Quarkus development. These tests are then run using your project's `Maven` build, specifically the `./mvnw test` command. Atlas will prompt for permission before executing this command, ensuring you maintain control over your build environment. This immediate testing feedback loop confirms the fix's efficacy and prevents future regressions. Furthermore, Atlas integrates with your project's `Spotless` formatter. Before committing any changes, Atlas can apply `Spotless` to ensure the code adheres to your project's formatting standards, maintaining code quality and consistency across your Quarkus codebase. This comprehensive approach, from `edit` to `JUnit 5` testing and `Spotless` formatting, ensures that fixes are not only effective but also maintainable and integrated into your standard Quarkus development practices. ## Atlas's Safety and Review for Quarkus Code Changes Atlas prioritizes safety and developer control throughout the Quarkus bug-fixing workflow, implementing multiple review gates before any code is written. Every Atlas tool call is permission-gated, and all proposed file edits are presented as a unified diff for your approval, ensuring 0 unexpected changes to your `application.properties` or Java source files. Atlas is designed with a strong emphasis on safety and transparency, crucial when making changes to a production Quarkus application. Before any tool, such as `edit` or `grep`, is executed, Atlas consults permission-gated allow, ask, and deny rules, giving you granular control over its actions. The workflow begins with a read-only plan agent that drafts a strategy for fixing the bug. This plan is presented to you for approval before Atlas switches to a build agent that can propose code modifications. For every file edit, Atlas computes a unified diff, clearly showing what changes will be made. This diff is surfaced for your explicit approval before Atlas writes anything to disk. This applies to all Quarkus-specific files, from Java source code to configuration files like `application.properties`. Atlas also snapshots file changes as git patches, allowing edits to be easily diffed, reviewed, and rolled back if necessary. Furthermore, Atlas reads your git branches, status, and diffs, and can stage and create commits on your behalf, integrating direct into your existing version control workflow for Quarkus projects. This multi-layered review process ensures that you, the Quarkus developer, are always in control of the changes being made. ## Steps 1. Paste the production stack trace into Atlas and let it `read` each frame's `file:line` at the reported offset within your Quarkus project. 2. If Atlas reports "Offset is out of range for this file," re-read the file from the top to ensure the trace matches your current Quarkus build. 3. Use Atlas's `grep` tool to search for the error message string from the stack trace, identifying where it is constructed in your Quarkus codebase. 4. Employ Atlas's `lsp` tool with the `findReferences` operation on the failing function to discover all callers that can reach it with the problematic input in your Quarkus application. 5. Instruct Atlas to `edit` the identified code to implement the necessary fix for the Quarkus bug. 6. Ask Atlas to add a new `@QuarkusTest` case, potentially using `RestAssured`, to serve as a regression test for the resolved issue. 7. Run your Quarkus tests using `./mvnw test` via Atlas, confirming the fix and ensuring no new regressions are introduced. 8. Review the unified diff presented by Atlas for the proposed changes, including any modifications to `application.properties` or Java source files. 9. Let Atlas apply `Spotless` to the modified files to maintain code formatting consistency before committing. 10. Approve Atlas to stage and create a commit for the fix and the new regression test in your Quarkus repository. ## FAQ ### How does Atlas handle Quarkus's build-time augmentation when tracing bugs? Atlas indexes code by AST declarations using tree-sitter, not blind line windows. This allows it to accurately map stack trace `file:line` pairs to your source code, even when Quarkus's build-time augmentation might alter compiled bytecode line numbers. It validates offsets against the current file to prevent misdirection. ### Can Atlas help ensure my Quarkus application adheres to native-image constraints? Yes, Atlas can be instructed to replace runtime reflection with build-time-friendly patterns. This ensures that your class structures and method calls are compatible with GraalVM native-image compilation, helping you avoid common native-image constraints and errors in Quarkus. ### How does Atlas integrate with the standard Quarkus testing workflow? Atlas direct integrates with `JUnit 5 (@QuarkusTest)`. It can add new `@QuarkusTest` cases, often using `RestAssured` for integration tests, and then run these tests using your project's `Maven` command (`./mvnw test`), providing immediate feedback on bug fixes. ### What safety mechanisms does Atlas provide when modifying Quarkus code? Atlas employs multiple safety layers. Every tool call is permission-gated, and it drafts a read-only plan before proposing changes. All file edits, including those to `application.properties` or Java source, are presented as a unified diff for your explicit approval before being written. ### How does Atlas prevent me from debugging with an outdated Quarkus stack trace? Atlas validates stack trace offsets against the current file content. If the `read` tool reports "Offset is out of range for this file," it indicates the trace is from a different build, prompting you to re-read the file from the top before trusting any line numbers. ### Can Atlas help maintain code quality in my Quarkus project? Absolutely. Atlas integrates with your project's `Spotless` formatter. After making code changes, Atlas can apply `Spotless` to ensure all modifications adhere to your defined code style and formatting rules before committing, maintaining consistency across your Quarkus codebase. ### How does Atlas manage dependencies and project structure in a Quarkus Maven project? Atlas operates within projects containing a `pom.xml` that pulls in `quarkus-bom`. It understands your project's structure, including CDI beans, JAX-RS resources, and `application.properties`, allowing it to navigate and modify your Quarkus application effectively. ### Does Atlas keep my Quarkus code local and secure? Yes, Atlas can build its code index with local Ollama embeddings, ensuring your proprietary Quarkus code remains on your local machine and off third-party servers. This commitment to local processing enhances security and privacy. --- Canonical HTML: https://runatlas.sh/resources/stacks/trace-a-runtime-bug-from-a-stack-trace-in-quarkus Source of truth: aeo_pages row `/resources/stacks/trace-a-runtime-bug-from-a-stack-trace-in-quarkus` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.