fix aborts returning 'missing' data and standardize to AbortSignal#17
fix aborts returning 'missing' data and standardize to AbortSignal#17
Conversation
…rd AbortSignal errors
There was a problem hiding this comment.
Code Review
This pull request refactors the abort handling logic by replacing the custom AbortError class with a utility function isAbortError and adopting native AbortSignal.throwIfAborted() calls. A significant change is made in IcechunkStore to propagate aborts and network errors instead of swallowing them, which prevents downstream consumers from caching empty or invalid data as valid results. Feedback was provided regarding a potential TypeScript compilation error in the isAbortError utility where a type cast is recommended to safely access the name property on an unknown object.
| typeof error === "object" && | ||
| error !== null && | ||
| "name" in error && | ||
| error.name === "AbortError" |
There was a problem hiding this comment.
Accessing error.name on a variable of type unknown will trigger a TypeScript compilation error in strict mode, as the base object type does not define a name property. Even with the "name" in error check, the compiler typically requires an explicit cast or a more specific type to access the property.
| error.name === "AbortError" | |
| (error as { name: unknown }).name === "AbortError" |
Fixes aborted reads being reported as missing data.
Refactors to standard AbortSignal instead of custom AbortError class.