Random InvalidOperationException from DisposableCallback #24
Comments
|
@JEnrightDev Could you check out my source code and run against that instead of the DLLs? I'd like you to change the code like so
That would help a lot! |
|
The Disposable callback is being created from here: https://github.com/mrpmorris/Fluxor/blob/master/Source/Fluxor.Blazor.Web/Components/FluxorComponent.cs#L29 Stack trace is as follows: |
|
After further digging, this is 100% a PEBKAC issue. In my "Index", I was overriding the OnIntitializedAsync method, but calling base.OnInitialized() instead of OnInitializedAsync, which skips the component initialization. I only managed to catch this by looking through the source and slowly piecing it together. Maybe a mechanism should be added to make this obvious, or a change in documentation? |
|
Ah, well done! What improvements do you have in mind? |
|
I'm not quite sure. But maybe passing along something like a "tag" or something to the DisposableCallback so that the exception message can be made clearer about where the "owner" of the callback is. That, plus a little extra documentation about that exception in particular would probably help quite a bit. |
|
It's really just a helper class that I didn't expect anyone to use. Your tag idea is pretty good though. Shame I can't have it create a StackTrace only when compiling in Debug. |
|
Well, that idea works if you're willing to compile from source to debug. #if DEBUG
_stackTrace = new StackTrace();
#endif |
|
Yeah, but I don't release debug binaries. That's why it's a shame :) |
mrpmorris
added a commit
that referenced
this issue
May 2, 2020
Add Id to help identify the origin of any instance of DisposableCallback that is not disposed of.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unfortunately, I don't have a lot of information available here, as the exception isn't really all that useful. At random times, we will receive an InvalidOperationException after executing an effect multiple times. It seems as though it's after the 2nd, 3rd, or 4th invocation of the same effect. (NOTE: the effect makes a couple of database calls, so everything is async using the new ConfigureAwait(false) fix)
I'm trying to come up with a reproduction case, and will update accordingly when I have a simplified version of one.
Exception Details:
Using Blazor Web (Server) and the 3.1.1 preview build.
The text was updated successfully, but these errors were encountered: