-
Notifications
You must be signed in to change notification settings - Fork 5k
Possible Solution idea to ChangeToken.OnChange firing several times. #43129
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
Comments
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process. |
It seems to me that debouncing OnChange callback firings is best left up to the user since any change could be "breaking" for other users. The determination on what kind of behaviour best suits the use case should not be made by the framework. |
Tagging subscribers to this area: @eerhardt, @maryamariyan |
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process. This process is part of our issue cleanup automation. |
This issue will now be closed since it had been marked |
Is your feature request related to a problem? Please describe.
Yes, it is related to the problem already described in dotnet/aspnetcore#2542, which is the fact that ChangeToken.OnChange fires more than once for a single change.
I would post this idea in that issue, but it is closed, so I had to open this new one.
Describe the solution you'd like
My solution idea, which I used in my project and worked for me, is to, instead of trying to consider only the last OnChange call, to consider only the very first call, and ignore subsequent calls by adding a "cool down period".
I am not sure if this solution is good for all cases, since I was not able to find out if the changes are guaranteed to be complete on the first call, but if that is the case, then this would solve the problem without introducing a delay on the OnChange execution.
Also, not sure if this solution would "solve this without regressing other scenarios", as was mentioned in dotnet/aspnetcore#2542 as the reason for not implementing it in the framework.
I could use some help in answering those questions :)
And, if the answers are that the change is guaranteed to be complete on the first call, and such a solution would not regress other scenarios, here is the way I implemented it in my code, and tested in aspnetcore 3.1:
This way, the first time the method is called, it will be able to acquire the semaphore and will run normally. Also, it will start the timer to release the semaphore only after the coolDownPeriod has passed.
Since all calls happen almost at the same time, the following calls will return for not being able to acquire the semaphore immediately.
Please let me know if the solution is not clear enough, or if I missed some important detail.
Edit: If the answer to the questions is that the solution would be good enough, I can make a generalized version of it and submit a PR. Let me know if this is the case, please.
The text was updated successfully, but these errors were encountered: