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] - Arvados

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:

Peter Amstutz

Category:

Target version:

2021-05-26 sprint

Start date:

05/21/2021

Due date:

% Done:

100%

Estimated time:

(Total: 0.00 h)

Story points:

Release:

Arvados 2.2.2

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

Related issues

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 <peter.amstutz@curii.com>

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

Blocks Story #17512: Release Arvados 2.2 added

#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.

#7 Updated by Peter Amstutz about 1 year ago

17702-wb1-bypass-fed @ e5828e5166afc24bba4559e8df3000523595e298

developer-run-tests: #2489

#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