You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
which summarizes as - we do not adjust "modified" time stamp of the dandiset even if zarr is modified (some files uploaded/changed) whenever it is never finalized. I think we should have some periodic job which would go through Pending zarrs, and if it was put into Pending state longer before the time window we allow for uploads/changes to happen in zarr -- "forcefully" finalize it in current state
NB in principle, whenever we have versioning implemented, we could revert back by removing versions of modifications to the keys and DeleteMarkers possibly added. But since we do not track to that level ATM, we cannot revert AFAIK. Also reversal might introduce the need to add similar reversal in backups2datalad (or just to not update Zarr until finalized into specific version), thus the easiest is just to finalize.
Another way to go about this is to send recurring emails to dandiset owners if zarrs/blobs have been lingering in an unfinished state. This would encourage them to take action on those stale files.
@jjnesbitt - i think this is where the ui thought process may have come, and it came up in the context of unembargoing blobs. we perhaps need something to finalize or cancel blobs or zarrs on the ui side in addition to reminders. i don't know if the user has any option to cancel an unfinished upload now or to find it.
Instigator:
which summarizes as - we do not adjust "modified" time stamp of the dandiset even if zarr is modified (some files uploaded/changed) whenever it is never finalized. I think we should have some periodic job which would go through Pending zarrs, and if it was put into Pending state longer before the time window we allow for uploads/changes to happen in zarr -- "forcefully" finalize it in current state
NB in principle, whenever we have versioning implemented, we could revert back by removing versions of modifications to the keys and DeleteMarkers possibly added. But since we do not track to that level ATM, we cannot revert AFAIK. Also reversal might introduce the need to add similar reversal in backups2datalad (or just to not update Zarr until finalized into specific version), thus the easiest is just to finalize.
I think it might relate to
The text was updated successfully, but these errors were encountered: