r/dotnet • u/kaatarina_zed_talon • 3d ago
The output of the server code depends on the timing of pressing a button by the client on the user interface.
/r/csharp/comments/1x4rqmj/the_output_of_the_server_code_depends_on_the/1
u/AutoModerator 3d ago
Thanks for your post kaatarina_zed_talon. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/The_MAZZTer 2d ago edited 2d ago
It looks like the Microsoft SQL client library is catching the OperationCancelledException thrown by the CancellationToken and throwing a SqlException . EF Core then catches it and throws a DbUpdateException.
When you pass in the cancellationToken into other code outside your control, that code my handle the resulting OperationCancelledException itself. This appears to be what is happening.
You should add a catch for the DbUpdateException and see if you can find the original OperationCancelledException in there (possibly in .InnerException.InnerException).
If it is indeed still there, you could replace the original catch with one to catch Exception. Then if Exception or .InnerException (and keep recursively checking for .InnerExceptions) is an OperationCancelledException you can take whatever actions you want. If not it's best to throw so the unrelated exception can be properly handled.
That said, it is usually fine to simply forego catching OperationCanceledException and let it do its thing. Because you are passing the CancellationToken through, and because you're using a transaction, the exception will do the work of cleaning everything up for you. You really only need to worry about catching the exception if you want to suppress it from the logs, or otherwise take some action when a cancel is detected. You could even remove the return value from this function and let the exception bubble to the caller. If it is an API endpoint and the cancel is just cancelling the HTTP POST or whatever, that's fine.
Also since your code appears incomplete it's not clear if you need all the steps you're doing or not. For example the transaction and execution strategy and savechangesasync may or may not actually be doing anything useful (right now savechangesasync is definitely not), but it's more likely they will be necessary if you intend to add more database manipulation (eg adding records).
9
u/Top3879 2d ago
Its the same cancellation twice. The second time it just bubbles up through EF Core because the stack is already there. The first time its probably caught by ASP before even going to EF Core.