janelia-flyem / dvid

Distributed, Versioned, Image-oriented Dataservice
http://dvid.io
Other
197 stars 33 forks source link

For tiny bodies, /sparsevol returns 404 at low resolution #369

Closed stuarteberg closed 2 years ago

stuarteberg commented 2 years ago

Of course, tiny bodies might "disappear" in the lower resolutions of our downscale pyramids. That means that their /sparsevol representation "doesn't exist" if you use a sufficiently high scale parameter. But I wouldn't expect a 404 in that case; I'd expect an empty result (with a status 200).

Here's an example from the hemibrain v1.2 release, for this body. The first URL returns a valid result (scale=4). The second returns a 404 (scale=5).

http://emdata4.int.janelia.org:8900/api/node/31597d/segmentation/sparsevol/1256567648?scale=4

http://emdata4.int.janelia.org:8900/api/node/31597d/segmentation/sparsevol/1256567648?scale=5
DocSavage commented 2 years ago

This error was hit again for the following: https://emdata5.janelia.org/api/node/31597d95bd844060b0ccc928a1a8a0a4/segmentation/sparsevol/1574160129?scale=0&minx=25844&maxx=25844&miny=28670&maxy=28670&minz=22204&maxz=22204 Given that the label index should give a fast way to screen at level 0 before using downres scale, we should be able to give better results like a 200 with empty as suggested above.

DocSavage commented 2 years ago

@stuarteberg In looking at the fix, We want status code 200 and no data returned if there's no voxels at a given scale. What should happen if there are no data within bounds specified as minx, maxx, etc? Would this break downstream apps that assume it will get a 404 if there's nothing there? I think the most consistent return would be to return 200 with nothing if there were blocks within bounds but no data at the scale, and 404 if there were no blocks in the bounds.

stuarteberg commented 2 years ago

I think I disagree. I would expect 200 in both cases. Either way, I wouldn’t worry about current apps. I don’t think we depend on 404 behavior. And I don’t know if anyone is currently using the minx/maxx feature (though we probably should).

DocSavage commented 2 years ago

OK, it's simpler to just return 200 so wound up doing that.