refuses to publish dandiset claiming it has a zarr whenever it (no longer) does

[yarikoptic]

on https://dandiarchive.org/dandiset/000029/draft

likely I had zarr before so there might be "association back" but now it is clear of zarrs

❯ curl --silent -X 'GET' 'https://api.dandiarchive.org/api/dandisets/000029/versions/draft/assets/?page_size=1000&metadata=false' -H 'accept: application/json' | jq '.results[].zarr'
null
null
null
null
null

and should be publishable, so I think the check should be fixed

[waxlamp]

I agree that this Dandiset should be publishable.

The check for Zarrs is done by hitting a Zarr endpoint (e.g. https://api.dandiarchive.org/api/zarr/?dandiset=000029) but apparently we don't remove the Zarr's Dandiset association when the asset itself is deleted from the Dandiset. We could instead use the assets endpoint, looking for assets with a non-null zarr property (or, more likely, a custom DB query that delivers this information more efficiently).

Some day (when versioned Zarrs are a real thing) all of this stuff will become moot. In the short term, I think a more accurate test for Zarr membership is the key. @jjnesbitt and/or @mvandenburgh could you weigh in on this?

[jjnesbitt]

This is one of the consequences of our zarr implementation, which is that zarrs have a direct link to a dandiset, alongside the normal route through assets. This means that when an asset is "deleted" from a dandiset (really just disassociated with the draft version), the zarr and corresponding link to the dandiset remains. There is currently no way to delete zarrs.

Long term, the appropriate thing to do might involve removing that direct link, in favor of the standard relation (dandiset <-> versions <-> assets), which likely requires a versioned zarr implementation. Short term I agree we should change how we check for zarrs, by querying assets of the draft version.

My idea is fairly inline with what @waxlamp already proposed, although I'd suggest we add a ?zarr=true query param to the version assets endpoint. This would filter the response to only include zarr assets, rather than exhaust the paginated assets endpoint, and the same check that's currently performed could remain (count > 0).