spring-projects / spring-projects/spring-modulith

Question why stacktrace of failed events is not persisted in EventPublicationRegistry

Open
#1,698 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
1.2k
Forks
222
PR merge metrics
No merged PRs in 30d

Description

Hi Spring Modulith Team,

While building a UI around the event publication registry, we noticed that failed event executions currently do not persist the underlying exception / stacktrace together with the failed event. Having the failure reason directly available in the persisted event state would make troubleshooting much easier, as users would not need to search through distributed application logs to understand why an event failed.

Looking at the implementation in CompletionRegisteringAdvisor, it seems that the exception is available at the point where the event is marked as failed. So I was wondering if there was a specific design decision why the stacktrace (or at least the exception message) is intentionally not persisted alongside the failed event?
I think it could easily passed to org.springframework.modulith.events.core.EventPublicationRegistry#markFailed and be persisted in the org.springframework.modulith.events.core.EventPublicationRegistry.

Just curious about the rationale here — maybe there are concerns about storage size, serialization, performance, security, or portability that I am missing?

Cheers Claudio

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading CompletionRegisteringAdvisor and EventPublicationRegistry#markFailed, where the issue says the exception is available and failure is recorded. Check the event publication persistence implementation and existing tests for how failed state is stored. Done would require an agreed decision on whether failure details should be persisted, plus corresponding behavior and coverage if the feature is accepted.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, spring-boot
Domain
backend, databases
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.