Bug #17424
open
[API] group contents endpoint edge cases with filter on uuid
0%
Description
The /groups/{uuid}/contents endpoint collects data from a number of tables, concatenates the results, and returns them. If a paging filter like "uuid" > "xxxx" is used that query, bad things happen - some results are no longer included in the output.
That is because the order in which the tables are processed is not the alphabetic sorting order of the object identifier but rather:
klasses = [Group,
Job, PipelineInstance, PipelineTemplate, ContainerRequest, Workflow,
Collection,
Human, Specimen, Trait]
That's
- j7d0g (Group)
- 8i9sb (Job)
- d1h4v (PipelineInstance)
- p5p6p (PipelineTemplate)
- xvhdp (ContainerRequest)
- 7fd43 (Workflow)
- 4zz18 (Collection)
- 7a9it (Human)
- j58dm (Specimen)
- q1cn2 (Trait)
Reordering the table list to be in consulted in alphabetical order would solve the problem for the (common) case where all UUIDs are local to the cluster. If there are other cluster UUIDs in those tables, though, the problem will persist, so we need a solution that's a bit more sophisticated. Performance will need to be a consideration.
Updated by
Updated by Tom Clegg almost 4 years ago
If I'm following correctly, this issue is "groups#contents should implement order=uuid correctly even when results are returned from multiple tables".
If this can't happen right away, it might be worthwhile to do "ensure groups#contents returns an error (instead of incorrectly sorted results) if the requested order is not supported". It sounds like the only case where "order" is implemented correctly is where the results are restricted to a single table via ["uuid","is_a","arvados#singleKind"] or ["uuid","is_a",["arvados#singleKind"]].
Updated by