[JAVA-5249] CommandEvent publisher catches all exceptions Created: 22/Nov/23  Updated: 15/Dec/23  Resolved: 15/Dec/23

Status: Closed
Project: Java Driver
Component/s: Command Logging and Monitoring
Affects Version/s: 4.9.0
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: chaoyang jia Assignee: Slav Babanin
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File image-2023-11-22-22-05-37-948.png    

 Description   

When I used "CommandListener", I encountered the problem of exception being caught. My scenario is that if no condition (Filter) is specified when modifying or deleting, an exception will be thrown, which is considered a dangerous operation, but in the end I threw The exception was caught by the sendCommandStartedEvent method of the ProtocolHelper class. After the capture, it was not thrown again, causing my program to continue executing and all collection data to be deleted. Is there any way to bypass the capture, or is there anything else? The method allows me to obtain it before the statement is executed, such as the interceptor in MyBatis



 Comments   
Comment by PM Bot [ 15/Dec/23 ]

There hasn't been any recent activity on this ticket, so we're resolving it. Thanks for reaching out! Please feel free to reopen this ticket if you're still experiencing the issue, and add a comment if you're able to provide more information.

Comment by PM Bot [ 07/Dec/23 ]

Hi j15030047216@163.com! JAVA-5249 is awaiting your response.

If this is still an issue for you, please open Jira to review the latest status and provide your feedback. Thanks!

Comment by Slav Babanin [ 29/Nov/23 ]

Hi j15030047216@163.com. Thank you for reaching out!

The CommandListener API is designed to receive and handle events without directly influencing command execution. Its primary role is to inform listeners about commands sent and replies received. The API shouldn't be used to execute custom logic around specific commands to determine success or failure.

I'd suggest validating queries at the application level to ensure safety.

Comment by chaoyang jia [ 28/Nov/23 ]

I temporarily threw another subclass of 'Error' of the 'Throwable' class to solve this problem, but I still want to know why the exception should be caught and not thrown twice. Will there be other security risks? If so, I hope you can tell me and I will consider whether what I am doing is right.

Comment by chaoyang jia [ 22/Nov/23 ]

This also caused me to be unable to roll back the transaction when I caught the exception.
Is the purpose of the Mongo team doing this to avoid some risks? If so, I hope you can tell me so I can weigh the pros and cons.

Comment by PM Bot [ 22/Nov/23 ]

Hi j15030047216@163.com, thank you for reporting this issue! The team will look into it and get back to you soon.

Generated at Thu Feb 08 09:04:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.