Add method for transactional publishing #58
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Reviewer's GuideThis PR adds an overloaded publish method to EventBusMessageBroker that handles TransactionalEvent by persisting it via the existing Publisher API, then broadcasting it over the EventBus with structured debug and error logging. Sequence diagram for transactional event publishing in EventBusMessageBrokersequenceDiagram
participant EventBusMessageBroker
participant Publisher
participant EventBus
participant Logger
EventBusMessageBroker->>Logger: log("Publishing event to topic {} with id {}")
EventBusMessageBroker->>Publisher: publish(event.event(), event.connection(), topic)
EventBusMessageBroker->>EventBus: publish("events." + topic, event)
EventBusMessageBroker->>Logger: log("Successfully published event to topic {} with id {}")
alt Exception occurs
EventBusMessageBroker->>Logger: log("Failed to publish event to topic {} with id {}", error)
end
Class diagram for updated EventBusMessageBroker with TransactionalEvent publishingclassDiagram
class EventBusMessageBroker {
+publish(String topic, Event event)
+publish(String topic, TransactionalEvent event)
}
class TransactionalEvent {
+id()
+event()
+connection()
}
class Publisher {
+publish(Event event, Connection connection, String topic)
}
EventBusMessageBroker --> TransactionalEvent
EventBusMessageBroker --> Publisher
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey there - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `vertx/src/main/java/com/p14n/postevent/vertx/adapter/EventBusMessageBroker.java:173` </location>
<code_context>
+
+ }
+
+ // First, persist to database using existing Publisher
+
+ }
</code_context>
<issue_to_address>
**nitpick:** Comment placement is misleading after the code block.
Move the comment above the Publisher.publish call to better reflect the actual sequence of operations.
</issue_to_address>
### Comment 2
<location> `vertx/src/main/java/com/p14n/postevent/vertx/adapter/EventBusMessageBroker.java:144` </location>
<code_context>
throw new RuntimeException("Failed to publish event", e);
}
}
+ public void publish(String topic, TransactionalEvent event) {
+
+ logger.atDebug()
</code_context>
<issue_to_address>
**issue (complexity):** Consider refactoring the repeated logging and error handling in publish methods into a helper to simplify the code.
Consider extracting the repeated logging + try/catch into a small helper. For example:
```java
@FunctionalInterface
private interface ThrowingRunnable {
void run() throws Exception;
}
private void doPublish(String topic, String eventId, ThrowingRunnable action) {
logger.atDebug()
.addArgument(topic)
.addArgument(eventId)
.log("Publishing event to topic {} with id {}");
try {
action.run();
logger.atDebug()
.addArgument(topic)
.addArgument(eventId)
.log("Successfully published event to topic {} with id {}");
} catch (Exception e) {
logger.atError()
.addArgument(topic)
.addArgument(eventId)
.setCause(e)
.log("Failed to publish event to topic {} with id {}");
throw new RuntimeException("Failed to publish event", e);
}
}
```
Then your two `publish` overloads become:
```java
public void publish(String topic, Event event) {
doPublish(topic, event.id(), () -> {
Publisher.publish(event, topic);
});
}
public void publish(String topic, TransactionalEvent txEvent) {
doPublish(topic, txEvent.id(), () -> {
Publisher.publish(txEvent.event(), txEvent.connection(), topic);
eventBus.publish("events." + topic, txEvent);
});
}
```
This removes the duplicated logger invocations, nested try/catch, and the stray comment, while keeping all behavior intact.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
|
||
| } | ||
|
|
||
| // First, persist to database using existing Publisher |
Contributor
There was a problem hiding this comment.
nitpick: Comment placement is misleading after the code block.
Move the comment above the Publisher.publish call to better reflect the actual sequence of operations.
| throw new RuntimeException("Failed to publish event", e); | ||
| } | ||
| } | ||
| public void publish(String topic, TransactionalEvent event) { |
Contributor
There was a problem hiding this comment.
issue (complexity): Consider refactoring the repeated logging and error handling in publish methods into a helper to simplify the code.
Consider extracting the repeated logging + try/catch into a small helper. For example:
@FunctionalInterface
private interface ThrowingRunnable {
void run() throws Exception;
}
private void doPublish(String topic, String eventId, ThrowingRunnable action) {
logger.atDebug()
.addArgument(topic)
.addArgument(eventId)
.log("Publishing event to topic {} with id {}");
try {
action.run();
logger.atDebug()
.addArgument(topic)
.addArgument(eventId)
.log("Successfully published event to topic {} with id {}");
} catch (Exception e) {
logger.atError()
.addArgument(topic)
.addArgument(eventId)
.setCause(e)
.log("Failed to publish event to topic {} with id {}");
throw new RuntimeException("Failed to publish event", e);
}
}Then your two publish overloads become:
public void publish(String topic, Event event) {
doPublish(topic, event.id(), () -> {
Publisher.publish(event, topic);
});
}
public void publish(String topic, TransactionalEvent txEvent) {
doPublish(topic, txEvent.id(), () -> {
Publisher.publish(txEvent.event(), txEvent.connection(), topic);
eventBus.publish("events." + topic, txEvent);
});
}This removes the duplicated logger invocations, nested try/catch, and the stray comment, while keeping all behavior intact.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
New Features: