Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Unify error message structure in EventBusBridge#2701

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
EmadAlblueshi wants to merge1 commit intovert-x3:master
base:master
Choose a base branch
Loading
fromEmadAlblueshi:fix-issue/2693

Conversation

@EmadAlblueshi
Copy link
Contributor

@EmadAlblueshiEmadAlblueshi commentedJan 17, 2025
edited
Loading

Motivation:

The message structure should be consistent to all error messages inEventBusBridge. The following is a list of a consistent error types with descriptive messages:

Type : INVALID_JSONMessage : Malformed JSON
Type : MISSING_TYPEMessage : Message type is missing
Type : INVALID_TYPE Message : Invalid message type
Type : MISSING_ADDRESSMessage : Message address is missing
Type : REJECTEDMessage : Message is rejected
Type : HANDLERS_MAX_LIMITMessage : Registration handlers exceed maximum limit
Type : ADDRESS_MAX_LENGTHMessage : Address exceeds maximum length
Type ADDRESS_ALREADY_REGISTEREDMessage : Address is already registered
Type ADDRESS_REGISTRATIONMessage : Address registration is failed
Type : ACCESS_DENIEDMessage : Address access is denied
Type : INVALID_REPLY_ADDRESSMessage : Reply address is invalid
Type : AUTHZMessage : Authorization failed
Type : AUTHNMessage Authentication is required
Type SOCKET_EXCEPTIONMessage : A socket exception occurred while attempting to establish or maintain a network connection

ThefailureCode for the above is-1 and all types with messages are tested except forSOCKET_EXCEPTION which I didn't find any unit test for such a use case so I added generic descriptive message in case theThrowable#getMessage() isnull.

Finally, this PR addresses inconsistency of all error messages inEventBusBridge#2693

Thanks!

@EmadAlblueshi
Copy link
ContributorAuthor

Ping@tsegismont :)

@EmadAlblueshi
Copy link
ContributorAuthor

EmadAlblueshi commentedJan 17, 2025
edited
Loading

Regarding the behavior of theEventBusBridge, error message types should be categorized after reporting to determine whether to maintain the connection or close it immediately.

The primary objective is to minimize any potential attempts to exploit connection resources or expose security vulnerabilities.

For example, if the message is invalid or the authentication is required why we should keep the connection maintained?

At present, I believe it is necessary to improve the behavior of theEventBusBridge to address those edge cases more effectively.

I’m happy to know and learn more from you!@tsegismont@vietj

@EmadAlblueshiEmadAlblueshi marked this pull request as draftJanuary 18, 2025 23:19
Signed-off-by: Emad Alblueshi <emad.albloushi@gmail.com>
@EmadAlblueshiEmadAlblueshi marked this pull request as ready for reviewJanuary 18, 2025 23:44
privatestaticvoidreplyError(SockJSSocketsock,Stringerr) {
JsonObjectenvelope =newJsonObject().put("type","err").put("body",err);
privatestaticvoidreplyError(SockJSSocketsock,Stringtype,Stringmessage) {
JsonObjectenvelope =newJsonObject()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I think we need to keep the old behavior as well to avoid breaking change and test it.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@vietj Do you mean using 'body' key for error messages?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

yes

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@vietj

IMHO the existing behavior should be changed you can check the Vert.x TCP EventBus bridge uses “message” key instead of “body” to report descriptive message for error type messages.

https://github.com/vert-x3/vertx-tcp-eventbus-bridge/blob/master/src/main/java/io/vertx/ext/eventbus/bridge/tcp/impl/protocol/FrameHelper.java#L86

Copy link
Contributor

@vietjvietj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This looks like a good change to me, however it brings breaking changes in the formatting of the json error.

We should keep the old behavior and test it to ensure people migrating from Vert.x 4 will not have unexpected issues.

@vietjvietj added this to the5.0.0 milestoneJan 20, 2025
Stringaddress =msg.getString("address");
if (address ==null) {
replyError(sock,"missing_address");
replyError(sock,"MISSING_ADDRESS","Message address is missing");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

we should define those in an package protected enum instead of havingthem scattered in the code base

@EmadAlblueshi
Copy link
ContributorAuthor

This looks like a good change to me, however it brings breaking changes in the formatting of the json error.

We should keep the old behavior and test it to ensure people migrating from Vert.x 4 will not have unexpected issues.

Honestly, If we keep the formatting of the json error as is this won't reflect the purpose of the PR and will be only for error types revamping fromString toEnum. is this what you recommend?

@vietjvietj modified the milestones:5.0.0,5.1.0May 14, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@vietjvietjvietj requested changes

Assignees

No one assigned

Labels

None yet

Milestone

5.1.0

Development

Successfully merging this pull request may close these issues.

2 participants

@EmadAlblueshi@vietj

[8]ページ先頭

©2009-2025 Movatter.jp