Sure an upstream issue would be welcome. Thanks for unpacking that further Mark 😀

And actually, zarr provides a data argument in create_dataset that actually encounters the same bug python import zarr import numpy as np name = 'hello' data = np.array('world', dtype='<U5') store = zarr.ZipStore('test_store.zip', mode='w') root = zarr.open(store , mode='w') zarr_array = root.create_dataset(name, data=data, shape=data.shape, dtype=data.dtype) zarr_array[...]

I guess i can open upstream in zarr, but I think for catching the 0 sized array case, it is probably best to use the data argument.

I think the reason is that for zero sized arrays, you technically aren't allowed to write data to them.

https://github.com/pydata/xarray/blob/6378a711d50ba7f1ba9b2a451d4d1f5e1fb37353/xarray/backends/zarr.py#L449

This means that when you create the 0 sized array, you can't actually change the value.

Here is a reproducer without xarray python import zarr import numpy as np name = 'hello' data = np.array('world', dtype='<U5') store = zarr.ZipStore('test_store.zip', mode='w') root = zarr.open(store , mode='w') zarr_array = root.create_dataset(name, shape=data.shape, dtype=data.dtype) root[name][...] = data zarr_array[...]

Though the code path follows what xarray does in the backend.

Sorry I don't know. Maybe @rabernat can advise? 🙂

@jakirkham not sure if you have any thoughts on why the code above is bugging out.

Honestly, i've found that __ coordinates are treated as less strict coordinates, so I've been using those.

Keeping things like: * The version of different software that was used.

Seems more like an attribute, but really, it is all data, so :/.

Regarding the originally issue, it seems that you are right in the sense that a 0 dimension string might be buggy in zarr itself.

I guess we (when we have time) will have to dig down to find a MVC example that reproduces the issue without xarray to submit to Zarr.

Thanks for the alternative repro. And I'm fairly confident this is a zarr issue; if the format can't handle a zero-dimensioned coord, it should raise a specific error rather than it being a bad ZipFile

I've avoided attrs since they often get "lost" in computation, and don't get dragged along as rigorously as coordinates.

Yeah, we're gradually fixing this. You can set a config to keep attrs by default, or pass keep_attrs=True in most methods. We might still be missing a couple of methods; would appreciate a bug report for any of those.

Hmm, interesting!

I've avoided attrs since they often get "lost" in computation, and don't get dragged along as rigorously as coordinates.

I do have some real coordinates that are stored as strings.

Thanks for the quickfeedback.

Here is the reproducing code without using context managers (which auto clsoe things you know)

```python import xarray as xr import zarr x = xr.Dataset() x['hello'] = 'world' x with zarr.ZipStore('test_store.zip', mode='w') as store: x.to_zarr(store)

read_store = zarr.ZipStore('test_store.zip', mode='r')
x_read = xr.open_zarr(read_store).compute()

The error will happen before this line is executed

read_store.close()

```

I had a quick debug but didn't completely resolve it. It works fine if you add it as an attribute; do you mean to be adding a single string as a data variable?

```python

In [8]: import xarray as xr ...: import zarr ...: x = xr.Dataset() ...: x.attrs['hello'] = 'world' # changed ...: x ...: with zarr.ZipStore('test_store.zip', mode='w') as store: ...: x.to_zarr(store) ...: with zarr.ZipStore('test_store.zip', mode='r') as store: ...: x_read = xr.open_zarr(store).compute() ...: ```

Debugging is non-trivial because the ZipFile is closed by the time I could run %debug. It's not impossible but would take more than a quick look in a repl. That said, I do think this looks likely to be a zarr issue given it depends on the storage format that zarr is using. It's possible xarray is calling it incorrectly but I'd think it's less likely.

@hmaarrfk my apologies, I misread your issue and it was always reproducible. I had thought it was referencing a file test_store.zip when actually it was writing it, mea culpa.

I will have to try the debugging things you mentionned some later time :/

Not sure if the builds in https://github.com/pydata/xarray/pull/3888 help reproduce things or not?

hmm i didn't realize this. I"m running from conda-forge + linux.

Let me try on your CIs.

You did supply the traceback! But it's not reproducible. And consistent with https://github.com/pydata/xarray/issues/3831#issuecomment-595403356, it's difficult to attribute the break on examples like these.

You could try debugging into the return array[key.tuple] call, which is the last one in xarray, and identifying whether xarray is making a bad call or zarr is incorrectly failing?

See the zipstore example in my first comment

I thought I provided it, but in either case, here is my traceback

Do you have a reproducible example? Otherwise I'm not sure how to help resolve...

My guess is that that xarray might be trying to write to the store character by character???

Otherwise, not too sure.

Hi @hmaarrfk , I don't know this area of code well but attempting to ensure that we resolve the question.

Should this be an xarray or a zarr issue? Is there something you think xarray is doing incorrectly here?