Calculating ExpiresAt in validation of lock status #4827
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
|
Has Microsoft fixed this year in their SDK? |
phatboyg
force-pushed
the
develop
branch
2 times, most recently
from
60c8d7d
to
5e70659
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue that this PR is fixing was discussed here:
#4821
Basically, if a message is published with delay in an Azure Service Bus queue, and that message gets expired and the main queue is configured to forward expired messages to another queue, MassTransit consumer of the second queue is not triggered,
It is in fact Azure Service Bus issue that uses the original expiry date when forwarding message rather than re-calculating it based on the new queue, and when MassTransit validates that date, it is in the past and it rejects processing it by throwing an error.
I will follow up the issue with Microsoft as I believe it is the correct fix for them but since it is in Azure Service Bus core, not sure how long it will take.
The values of TimeToLive and EnqueuedTime of the message are correct and expiry date can be correctly re-calculated.