Explore 404 for `.zarray`

[tcompa]

When loading https://example.org/vizarr/?source=https://example.org/vizarr/data/shares/relative/path//20200812-CardiomyocyteDifferentiation14-Cycle1_mip.zarr/B/03/0 a GET call is made to https://example.org/vizarr/data/shares/relative/path//20200812-CardiomyocyteDifferentiation14-Cycle1_mip.zarr/B/03/0/.zarray

This file does not exist, as expected, because .../B/03/0 is an zarr group and not a zarr array. One such file does exist when we go one level deeper in the hierarchy (i.e. .../B/03/0/0/.zarray).

The 404 error is logged in the browser developer tools, but it does not prevent loading the actual image.

It would be useful to understand where this calls originates from (vizarr/zarrita), and possibly avoid it.

[zonia3000]

It seems to be the default behavior of zarrita. It tries to open an array, if it doesn't find it, it assumes it is a group.

return open_array_v2(loc, attrs).catch((err) => {
    if (err instanceof NodeNotFoundError) return open_group_v2(loc, attrs);
    throw err;
});

https://github.com/manzt/zarrita.js/blob/e10eaf697c4939dc33fb96db6f9a6a8dc6270a1d/packages/core/src/open.ts#L66

The open function also accepts an options parameter that can be used to tell if we want to open an array or a group, however, in the calls that produces the 404 error, the options object is empty, because it is called from vizarr open function (in utils.ts) that opens it using only the location object, without adding the options parameter.

The flow is as follow.

From vizarr utils.ts:

export async function open(source: string | Readable) {
  const location = await normalizeStore(source);
  return zarr.open(location);
}

Then goes to zarrita.js open(), than calls open_v2().

[tcompa]

Thanks for the clear explanation. Thus this is not a fractal-vizarr-viewer issue, and the error (corresponding to the 404 response) is already handled by zarrita's open_v2.

If in the future we want to improve this behavior, we should open an issue for vizarr (e.g. adding options={"kind": "group"}, depending on some user action or some configuration).

Closing this issue.

[jluethi]

Ah, great to know that this 404 isn't actually an issue, but basically expected behavior for this case! Thanks for looking into this Sonia!