spring-projects / spring-projects/spring-modulith

Managing Exceptions and Resubmissions in Events

Open
#1,332 3 comments 1 reaction 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

We have two questions/proposals:

1. Exception Handling in Event Listeners

Is there any way to control exceptions thrown within event listeners?

We’re using events to communicate between modules, but we’re unsure how to properly manage the different types of exceptions that may be thrown by a module.

We’re currently dealing with two types of exceptions:

  • Retryable exceptions – should trigger a resubmission.
  • Non-retryable exceptions – should mark the event as failed.

We attempted to handle this by creating an aspect that marks the event as failed. However, the only way we found to prevent an exception from being retried was to simulate multiple attempts until the scheduler stops picking up the event—based on resubmission options with a high attempt count. This approach feels quite hacky and not clean.

Additionally, we noticed that unless the exception is rethrown, Modulith marks the event as completed—even if we explicitly marked it as failed. This behavior seems counterintuitive.

Is there anything on the roadmap regarding better exception management for events?


2. Controlling Resubmission Behavior by Event Type

How can we control resubmission strategies based on different event types?

For example:

  • EventA should be resubmitted based on a duration.
  • EventB should be resubmitted based on completion attempts.

We explored ResubmissionOptions and the withFilter method, but couldn’t find a way to differentiate behavior based on event type.

Would it be feasible to expose the event type in the EventPublication object?
That could allow more granular control over resubmission logic.


Thanks in advance for your feedback!

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 ResubmissionOptions, its withFilter method, and EventPublication, then trace how listener exceptions and resubmissions are currently handled. The issue needs maintainer clarification before work can begin: whether exception classification, event-type-specific strategies, or exposing event type is wanted, along with the expected behavior and tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, spring-boot
Domain
backend, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.