Bug #17702

[workbench1] fiddlesticks on home page, cannot execute federated list query with limit (9223372036854775807) < nUUIDs (2), offset (1) > 0, or order ([]) parameter [API: 400]

Added by Ward Vandewege about 1 year ago. Updated 6 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
05/21/2021
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
Release relationship:
Auto

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.


Subtasks

Task #17712: Review 17702-wb1-bypass-fedResolvedTom Clegg


Related issues

Related to Arvados - Bug #17587: [Workbench] home page broken (#<ActionView::Template::Error: cannot execute federated list query with limit, offset, or order parameter [API: 400]>)Resolved05/04/2021

Blocks Arvados - Story #17512: Release Arvados 2.2Resolved05/03/2021

Associated revisions

Revision f752aedf
Added by Peter Amstutz 12 months ago

Merge branch '17702-wb1-bypass-fed' refs #17702

Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <>

History

#1 Updated by Ward Vandewege about 1 year ago

  • Description updated (diff)

#2 Updated by Ward Vandewege about 1 year 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

#3 Updated by Ward Vandewege about 1 year ago

#4 Updated by Peter Amstutz about 1 year ago

  • Assigned To set to Peter Amstutz

#5 Updated by Peter Amstutz about 1 year 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.

#6 Updated by Peter Amstutz about 1 year 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.

#8 Updated by Peter Amstutz about 1 year ago

  • Status changed from New to In Progress

#9 Updated by Peter Amstutz about 1 year ago

As Tom pointed out, bypass_federation can't be used by non-privileged users.

#10 Updated by Peter Amstutz 12 months 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.

developer-run-tests: #2490

#11 Updated by Tom Clegg 12 months 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.

#12 Updated by Peter Amstutz 12 months 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

developer-run-tests: #2491

#13 Updated by Tom Clegg 12 months ago

LGTM, thanks!

#14 Updated by Peter Amstutz 12 months ago

  • Status changed from In Progress to Resolved

#15 Updated by Peter Amstutz 6 months ago

  • Release set to 41

Also available in: Atom PDF