Arvados

17154-wb-profile @ c11f254a98e7caf437422d86eab38c7ba4f04096

The issue is that when you get a user record using "current user of token" it can fetch a stale user record from the local cluster. So even though the profile settings were written to the user record on the login cluster, the profile settings don't appear in the "current user" response because it is returning a cached record from the local cluster.

Explicitly fetching user record forces it to get a fresh record from the login cluster.

developer-run-tests: #2189

Another way to approach this would be to tweak controller so that user record updates also ensure that the update is sent to the local cluster.

I went and added the federated user update tweak.

17154-wb-profile @ 9d755d7dc0df6975e8b46cbaac6867abefdd138f

developer-run-tests: #2190

Review comments:

• In apps/workbench/app/controllers/users_controller.rb, dev profile, please add a comment about why it forces a user object re-read.

• in lib/controller/federation/conn.go, would the more generic solution be to force a cache refresh for the user object? Do we have infrastructure for that yet? Doing the update again on the local cluster seems like it could end us up in an undesirable situation with 2 diverging objects (e.g. if the local copy is already out of date, then the code would update the login cluster and then apply the update to the local cluster -- which would then have an object that's a mix of a stale object and the updated user profile).

9d755d7 -- should use !strings.HasPrefix() instead of options.UUID[:5]!=... to avoid crashing on short value (just good practice -- even though in this case an invalid UUID shouldn't get this far because UserUpdate would fail).

Ward Vandewege wrote:

Review comments:

• In apps/workbench/app/controllers/users_controller.rb, dev profile, please add a comment about why it forces a user object re-read.

Added comment.

• in lib/controller/federation/conn.go, would the more generic solution be to force a cache refresh for the user object? Do we have infrastructure for that yet? Doing the update again on the local cluster seems like it could end us up in an undesirable situation with 2 diverging objects (e.g. if the local copy is already out of date, then the code would update the login cluster and then apply the update to the local cluster -- which would then have an object that's a mix of a stale object and the updated user profile).

The update on the local cluster uses the update response from the home cluster. So it isn't like it is making the same change in both places, it is making the change, getting back a full copy of the object, and updating locally from that.

17154-wb-profile @ 0fe238d1f4240d22b2c58838b03a7607656652d3

developer-run-tests: #2192

Peter Amstutz wrote:

Ward Vandewege wrote:

Review comments:

• In apps/workbench/app/controllers/users_controller.rb, dev profile, please add a comment about why it forces a user object re-read.

Added comment.

• in lib/controller/federation/conn.go, would the more generic solution be to force a cache refresh for the user object? Do we have infrastructure for that yet? Doing the update again on the local cluster seems like it could end us up in an undesirable situation with 2 diverging objects (e.g. if the local copy is already out of date, then the code would update the login cluster and then apply the update to the local cluster -- which would then have an object that's a mix of a stale object and the updated user profile).

The update on the local cluster uses the update response from the home cluster. So it isn't like it is making the same change in both places, it is making the change, getting back a full copy of the object, and updating locally from that.

17154-wb-profile @ 0fe238d1f4240d22b2c58838b03a7607656652d3

developer-run-tests: #2192

Thanks, LGTM.