Tom White

That's what I thought too - but there is another wrinkle. In this diff https://github.com/tomwhite/sgkit/commit/e1119ca68f979cafec8ead9bd0c829de2e6e4d8e previously `metric_param` was initialized outside the function to prevent Dask serialization/deserialization time (see the comment)....

It's probably better to run against the v3 branch to pick up fixes as they are made.

See https://github.com/sgkit-dev/bio2zarr/issues/254

The main blocker here is Xarray support for Zarr Python v3.

> The main blocker here is Xarray support for Zarr Python v3. Fixed in [Xarray 2024.10.0](https://github.com/pydata/xarray/releases/tag/v2024.10.0)

Thanks for opening this @thodson-usgs! Using a local Lithops executor (or even just the default single-threaded Cubed executor on your local machine), might be helpful in isolating where the problem...

> Furthermore, I don't have a great strategy for debugging a Lambda-only failure mode. Does it work with Cubed running on local Lithops (https://lithops-cloud.github.io/docs/source/compute_config/localhost.html)?

Can you try with [Lithops localhost version 1](https://lithops-cloud.github.io/docs/source/compute_config/localhost.html#summary-of-configuration-keys-for-localhost) - that's what we use in the Cubed unit tests as version 2 had some problems when we last tried it. Another...

Thanks for the the instructions @thodson-usgs! I have managed to reproduce this - getting the `Object of type slice is not JSON serializable` error with the local lithops executor. With...

> Is that cubed's fault for not understanding dask-relevant kwargs, xarray's for passing them, or cubed-xarray somehow? We should raise an issue specifically to track this bug. Not sure. I...