-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
the processAcknowledgement
may process CompletionMessage
first for blocking incovation even the message is sent ahead of ResultMessage
#4134
Comments
processAcknowledgement
may process CompletionMessage
for blocking incovation even the message is sent ahead of ResultMessage
processAcknowledgement
may process CompletionMessage
first for blocking incovation even the message is sent ahead of ResultMessage
The DB poll is periodic and there is a race between getting the results from the poller vs active ack. Until the poll is cancelled (which is scheduled by the active ack), it remains active. Further, the future which continues with its callback could be executed in any order. Because of how close the log statements appear in time, I don't think the effect is necessarily what you might be hinting at: that the result message is ignored for completing the blocking request --- which you can assert with a test otherwise. I saw you opened a PR so will take a look at that as well. |
add
and found the warn log:
the reason why I found this is that we have a custom feature which can skip saving activations into DB when some request parameters are set, then some of these requests will hang until timeout and return a 202 response |
I ran into similar, and think it is due to:
In my case, I'm trying to ensure the activation db lookup is not done at controller, and disabling that db lookup locally makes the "first" activation fail - seems like the initial message parse is slower than subsequent ones. |
@tysonnorris also please take a look at #4145 (I think 4135 had a bug wrt that can affect blocking requests). |
Will take a look - I'm not sure these are related to the root symptom of result message sent before completion message, but completion message is processed first? Will test out both of these. |
In #4145 it looks like the result is used properly for blocking activations now; however, there is still suspicious/inappropriate order of kafka message handling, at least on the first activation in the controller; I'll create a separate PR for that, since in general I think we expect kafka messages processing to at least be triggered in order (not necessarily completed in order). |
Can you open an issue first to document the symptom - the info is scattered in a couple of prs I think. 🙏🏼 |
Environment details:
Steps to reproduce the issue:
Provide the expected results and outputs:
I think the expected result is not to fetch activation from database if
ResultMessage
contains that data:Provide the actual results and outputs:
but actually it's not
Additional information you deem important:
The text was updated successfully, but these errors were encountered: