Repository navigation
Interop calls cut off by disposal no longer throw (3.19.8.1) - #2
Merged
Merged
Conversation
A command or query still in flight when the component was disposed threw once the JS side went away. In a reloaded BlazorWebView the page no longer holds the instance, so the call fails with a JSException; elsewhere it is JSDisconnectedException, ObjectDisposedException or TaskCanceledException. Calls made after disposal already did nothing, but these were issued before it. A caller that fired one off without awaiting - the usual way to scroll a list back to the top after a filter change - saw it only as an unobserved task exception, so apps wrapped the calls in catches of their own: SatisFIT's exercise picker catches ObjectDisposedException around ScrollToTop, which misses the other three. InvokeInstance and QueryInstance now catch a failure that arrives after disposal started: a command completes, a query returns its default, and the failure is logged as teardown already does - Debug for the known ways the JS side goes away, Warning for anything else. A failure while the component is alive still throws. The render path had the same gap: a render's setOptions, setItems or measureRenderedRows in flight at disposal stopped the render when it succeeded, but escaped as an unhandled render exception when it failed. Those calls now go through InvokeInstance too. Tests: ScrollToTop in flight at disposal, for each of the four exceptions and an unexpected one (logged at Debug, Warning for the last); GetSnapshot in flight returns null; the render-race theory now also fails each held call. All nine fail without the catches. A failure while alive still throws.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2 +/- ##
==========================================
+ Coverage 67.82% 71.69% +3.86%
==========================================
Files 6 6
Lines 258 265 +7
Branches 41 41
==========================================
+ Hits 175 190 +15
+ Misses 73 64 -9
- Partials 10 11 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or 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
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.
Summary
This follows up on #1. A command or query that was still in flight when the component was disposed threw once the JS side went away. In a reloaded BlazorWebView that is a
JSException("JS object instance with ID n does not exist"). Elsewhere it isJSDisconnectedException,ObjectDisposedExceptionorTaskCanceledException. A call made after disposal already did nothing; these calls were issued before it.A caller that fires a call off without awaiting it, for example scrolling a list back to the top after a filter change, saw only an unobserved task exception. So apps wrapped the calls in catches of their own. SatisFIT's exercise picker catches
ObjectDisposedExceptionaroundScrollToTop, which misses the other three exceptions. ItsInvalidateItemSizecalls have no catch at all.Changes
InvokeInstanceandQueryInstancenow catch a failure that arrives after disposal has started. A command completes, a query returns its default, and the failure is logged the same way teardown already logs: Debug for the known ways the JS side goes away, Warning for anything else.setOptions,setItemsormeasureRenderedRowsthat was in flight at disposal stopped the render if it succeeded, but if it failed it escaped as an unhandled render exception. Those calls now go throughInvokeInstancetoo.Testing
ScrollToTopin flight at disposal, once for each of the four exceptions and once for an unexpected one: the task completes, and the failure is logged at Debug, or at Warning for the unexpected one.GetSnapshotin flight at disposal returnsnull.setOptions,setItems,measureRenderedRows), and checks that no unhandled render exception is reported.JSExceptionwhile the component is alive still throws.After merge
Kebechet.Blazor.TanStack.VirtualCoreto 3.19.8.1 and remove theObjectDisposedExceptioncatch inExerciseSearchBottomSheet.ScrollVirtualizedListToTop.