Bug #17702
closed
[workbench1] fiddlesticks on home page, cannot execute federated list query with limit (9223372036854775807) < nUUIDs (2), offset (1) > 0, or order ([]) parameter [API: 400]
100%
Description
This is happening on tordo, which is in a login federation with ce8i5.
Running workbench version 2.2.0~dev20210519161517-1, api server 2.2.0~dev20210519161517-1, controller 2.2.0~dev20210519161517-1.
When logged in as an admin user, the home page ("Dashboard") on tordo says:
Oh... fiddlesticks. Sorry, I had some trouble handling your request. cannot execute federated list query with limit (9223372036854775807) < nUUIDs (2), offset (1) > 0, or order ([]) parameter [API: 400]
This seems very similar to bug #17587.
Updated by Ward Vandewege almost 4 years ago
- Related to Bug #17587: [Workbench] home page broken (#<ActionView::Template::Error: cannot execute federated list query with limit, offset, or order parameter [API: 400]>) added
Updated by Ward Vandewege almost 4 years ago
- Blocks Story #17512: Release Arvados 2.2 added
Updated by Peter Amstutz almost 4 years ago
Here's part of the query:
[[\"uuid\",\"in\",[\"tordo-j7d0g-kb0pe6g60khpn98\",\"tordo-j7d0g-kb0pe6g60khpn98\",\"tordo-j7d0g-kb0pe6g60khpn98\",\"ce8i5-tpzed-xo2k4i24bjzwedw\",\"ce8i5-tpzed-xo2k4i24bjzwedw\", ...]]
The problem here is that we're asking for objects owned by both groups and users, and the users are federated, so in current logic this becomes a federated list query. As a result, the offset paging done by workbench1 gets the reported error.
Updated by Peter Amstutz almost 4 years ago
I think the best solution here is for workbench1 to specify "bypass_federation" on all its listing API calls. This doesn't affect multisite search (which is implemented completely separately) but avoids these kinds of problems in which queries behave differently.
I think the key issue is that our generic federated listing lacks the features to do reasonable paging.
Updated by Peter Amstutz almost 4 years ago
17702-wb1-bypass-fed @ e5828e5166afc24bba4559e8df3000523595e298
Updated by Peter Amstutz almost 4 years ago
- Status changed from New to In Progress
Updated by Peter Amstutz almost 4 years ago
As Tom pointed out, bypass_federation can't be used by non-privileged users.
Updated by Peter Amstutz almost 4 years ago
17702-wb1-bypass-fed @ f1aec3387f765a3f8a2f3f2c22d3a53fb4f9f1f3
Second try.
Add support for the cluster_id parameter to the federated listing in controller. Then, workbench uses cluster_id to explicitly request the listing from only its configured cluster.
Updated by Tom Clegg almost 4 years ago
It seems like the options.ClusterID check would be better off in splitListRequest, alongside the existing similar exception, to reduce the variety of code paths:
if opts.BypassFederation || opts.ForwardedFor != "" {
Other than that, this looks like a good solution.
Updated by Peter Amstutz almost 4 years ago
Tom Clegg wrote:
It seems like the options.ClusterID check would be better off in splitListRequest, alongside the existing similar exception, to reduce the variety of code paths:
[...]
Other than that, this looks like a good solution.
17702-wb1-bypass-fed @ e2d0ebb4cdeeb572226fc22a46bf60c507e111ea
Updated by Peter Amstutz almost 4 years ago
- Status changed from In Progress to Resolved