Skip to content

Upgrade to zarrita 0.7.2#398

Open
manzt wants to merge 1 commit into
allen-cell-animated:mainfrom
manzt:manzt/zarrita-upgrade
Open

Upgrade to zarrita 0.7.2#398
manzt wants to merge 1 commit into
allen-cell-animated:mainfrom
manzt:manzt/zarrita-upgrade

Conversation

@manzt
Copy link
Copy Markdown

@manzt manzt commented Apr 23, 2026

Zarrita 0.7.0 dropped the Store type generic on zarr.Array in favor of a composable store/array extension API. An audit of public repos using zarrita led me to find this project as the one consumer using the generic for something other than passing down an AbortSignal. I'm sorry for breaking your code.

The previous code threaded subscriber / reportChunk / isPrefetch through the store to drive the cache and request queue. This can now be done by wrapping the array with a per-request zarr.defineArrayExtension that captures the same context in its closure.

These changes follow the zarrita migration guide to port to that extension model, move RelaxedFetchStore's 403-handling onto FetchStore's new fetch handler option, and swap NodeNotFoundError / KeyError for the consolidated NotFoundError.

@manzt manzt requested a review from a team as a code owner April 23, 2026 23:18
@manzt manzt requested review from ShrimpCryptid and interim17 and removed request for a team April 23, 2026 23:18
@toloudis toloudis requested a review from frasercl April 24, 2026 00:48
@toloudis
Copy link
Copy Markdown
Contributor

Thank you for the PR! We will look at it asap...

@manzt
Copy link
Copy Markdown
Author

manzt commented Apr 24, 2026

Having a look a this again today. I think there are some newer type-inference features used by the extension API that your TypeScript (v4.7) version doesn't support, so the inferred return types are any. As an erasing compiler, it should be fine at runtime but wanted to callout so these changes don't quietly land without that understanding.

Would you be open to me making a PR to upgrade TypeScript first, and then we can rebase on that?

@toloudis
Copy link
Copy Markdown
Contributor

Having a look a this again today. I think there are some newer type-inference features used by the extension API that your TypeScript (v4.7) version doesn't support, so the inferred return types are any. As an erasing compiler, it should be fine at runtime but wanted to callout so these changes don't quietly land without that understanding.

Would you be open to me making a PR to upgrade TypeScript first, and then we can rebase on that?

Sure.
#395 moves to typescript 6 so maybe you could base your pr to that branch. It should merge soon.

@toloudis
Copy link
Copy Markdown
Contributor

toloudis commented Apr 28, 2026

Our typescript update branch has now merged to main ( #395 ). @manzt @frasercl

Zarrita 0.7 dropped the `Store` type generic on `zarr.Array` in favor of
a composable store/array extension API. An audit of public repos turned
up vole-core as the one consumer using the generic for something other
than passing down an `AbortSignal`. I'm sorry for breaking your code.

The previous code threaded `subscriber` / `reportChunk` / `isPrefetch`
through the store to drive the cache and request queue. This can now be
done by wrapping the array with a per-request
`zarr.defineArrayExtension` that captures the same context in its
closure.

These changes follow the zarrita migration guide
(https://zarrita.dev/migration/v0.7.html) to port to that extension
model, move `RelaxedFetchStore`'s 403-handling onto `FetchStore`'s new
`fetch` handler option, and swap `NodeNotFoundError` / `KeyError` for
the consolidated `NotFoundError`.
@toloudis
Copy link
Copy Markdown
Contributor

toloudis commented May 5, 2026

@manzt should we do anything here? If we just fixup the conflicts is there anything else to be modified?

@manzt manzt force-pushed the manzt/zarrita-upgrade branch from 7d56370 to 997f1d3 Compare May 5, 2026 20:42
@manzt
Copy link
Copy Markdown
Author

manzt commented May 5, 2026

I just rebased on main, fixed up issues, and pushed. Thinking it's in a good state.

Copy link
Copy Markdown
Contributor

@ShrimpCryptid ShrimpCryptid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple quick comments!

Comment on lines +40 to 43
const cached = opts.cache?.get(fullKey);
if (cached && isChunk(cached)) {
return cached;
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why this got renamed?

coords: TCZYX<number>,
subscriber: SubscriberId
): void {
const instrumented = withVoleInstrumentation(scaleLevel, {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might consider renaming this wrapper to be more descriptive... I feel like instrumented as a verb is not super descriptive to me. wrappedRequest? @frasercl might have more thoughts on this than I do

@interim17 interim17 removed their request for review May 11, 2026 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants