Is there an existing issue for this?
Description
There appears to be a redundant call to CancellationTokenProvider.FallbackToProvider in MedallionAbpDistributedLock.TryAcquireAsync.
Specifically, the code calls CancellationTokenProvider.FallbackToProvider(cancellationToken) as a standalone statement (without capturing its return value), and then calls the same method again in the parameter list of DistributedLockProvider.TryAcquireLockAsync, where the result is used. This standalone invocation has no effect, so it's very likely unnecessary and can be removed.
Reproduction Steps
-
Inspect the implementation of MedallionAbpDistributedLock.TryAcquireAsync in:
framework/src/Volo.Abp.DistributedLocking/Volo/Abp/DistributedLocking/MedallionAbpDistributedLock.cs
-
Locate the following code lines:
CancellationTokenProvider.FallbackToProvider(cancellationToken);
var handle = await DistributedLockProvider.TryAcquireLockAsync(
key,
timeout,
CancellationTokenProvider.FallbackToProvider(cancellationToken)
);
-
Observe that the first call does not have any effect and can be removed.
Expected behavior
The TryAcquireAsync method should only call FallbackToProvider where the result is actually used, to keep the code clean and reduce confusion.
Actual behavior
There is an additional redundant statement calling FallbackToProvider(cancellationToken) that has no effect. This could potentially confuse code readers.
Regression?
Unknown.
Known Workarounds
This is a minor code quality issue and does not affect functionality, so there is no workaround required.
Version
Current dev branch (2026-05)
User Interface
Common (Default)
Database Provider
None/Others
Tiered or separate authentication server
None (Default)
Operation System
Windows (Default)
Other information
Related file: https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.DistributedLocking/Volo/Abp/DistributedLocking/MedallionAbpDistributedLock.cs
The relevant lines are:
CancellationTokenProvider.FallbackToProvider(cancellationToken);
var handle = await DistributedLockProvider.TryAcquireLockAsync(
key,
timeout,
CancellationTokenProvider.FallbackToProvider(cancellationToken)
);
See also docs for FallbackToProvider:
https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Threading/Volo/Abp/Threading/CancellationTokenProviderExtensions.cs
Is there an existing issue for this?
Description
There appears to be a redundant call to CancellationTokenProvider.FallbackToProvider in MedallionAbpDistributedLock.TryAcquireAsync.
Specifically, the code calls CancellationTokenProvider.FallbackToProvider(cancellationToken) as a standalone statement (without capturing its return value), and then calls the same method again in the parameter list of DistributedLockProvider.TryAcquireLockAsync, where the result is used. This standalone invocation has no effect, so it's very likely unnecessary and can be removed.
Reproduction Steps
Inspect the implementation of MedallionAbpDistributedLock.TryAcquireAsync in:
framework/src/Volo.Abp.DistributedLocking/Volo/Abp/DistributedLocking/MedallionAbpDistributedLock.cs
Locate the following code lines:
CancellationTokenProvider.FallbackToProvider(cancellationToken);
var handle = await DistributedLockProvider.TryAcquireLockAsync(
key,
timeout,
CancellationTokenProvider.FallbackToProvider(cancellationToken)
);
Observe that the first call does not have any effect and can be removed.
Expected behavior
The TryAcquireAsync method should only call FallbackToProvider where the result is actually used, to keep the code clean and reduce confusion.
Actual behavior
There is an additional redundant statement calling FallbackToProvider(cancellationToken) that has no effect. This could potentially confuse code readers.
Regression?
Unknown.
Known Workarounds
This is a minor code quality issue and does not affect functionality, so there is no workaround required.
Version
Current dev branch (2026-05)
User Interface
Common (Default)
Database Provider
None/Others
Tiered or separate authentication server
None (Default)
Operation System
Windows (Default)
Other information
Related file: https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.DistributedLocking/Volo/Abp/DistributedLocking/MedallionAbpDistributedLock.cs
The relevant lines are:
See also docs for FallbackToProvider:
https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Threading/Volo/Abp/Threading/CancellationTokenProviderExtensions.cs