VCST-4564: Refactor payment processing to use async methods#485
Conversation
feat: Refactor payment processing to use async methods
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
src/VirtoCommerce.OrdersModule.Data/Handlers/CancelPaymentOrderChangedEventHandler.cs
Outdated
Show resolved
Hide resolved
|
src/VirtoCommerce.OrdersModule.Data/Handlers/CancelPaymentOrderChangedEventHandler.cs
Outdated
Show resolved
Hide resolved
vc-ci
left a comment
vc-ci
left a comment
There was a problem hiding this comment.
Test Suite: Test Suites/Modules/module_Assets
Tests: 13
Failures: 0
Errors: 0
Time: 7.781
Timestamp: 05-02-2026T16:16:29
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| var paymentToCancel = order.InPayments.FirstOrDefault(x => x.Id.EqualsIgnoreCase(jobArgument.PaymentId)); | ||
| if (paymentToCancel != null && !paymentToCancel.IsCancelled) | ||
| { | ||
| #pragma warning disable VC0012 |
There was a problem hiding this comment.
Async method unnecessarily blocks via sync-over-async wrapper
Medium Severity
The async method TryToCancelOrderPaymentsAsync calls the deprecated synchronous CancelPayment method, which internally uses .GetAwaiter().GetResult() to block on CancelPaymentAsync. This sync-over-async pattern inside an async method is inefficient and contradicts the PR's purpose of using async methods. The async method could directly await CancelPaymentAsync(paymentToCancel, order) instead of calling the blocking wrapper.
Additional Locations (1)
2 participants
Description
feat: Refactor payment processing to use async methods
References
QA-test:
Jira-link:
https://virtocommerce.atlassian.net/browse/VCST-4564
Artifact URL:
https://vc3prerelease.blob.core.windows.net/packages/VirtoCommerce.Orders_3.867.0-pr-485-b5bb.zip
Note
Medium Risk
Touches payment capture/refund/void paths and an API endpoint signature, so behavior/regressions depend on the new async Payment module methods and client compatibility with the added
CancellationTokenparameter.Overview
Refactors order payment flows to use the Payment module’s async APIs: post-processing (
ValidatePostProcessRequestAsync/PostProcessPaymentAsync), capture/refund (CaptureProcessPaymentAsync/RefundProcessPaymentAsync), and order payment cancellation now voids/refunds via async calls.Updates the
processPaymentcontroller actions to accept aCancellationTokenand callProcessPaymentAsync, and bumps Payment module package/dependency versions to3.813.0(plus a minor manifest copyright year update).Written by Cursor Bugbot for commit ad31072. This will update automatically on new commits. Configure here.