Arvados

This inconsistency might be due to federation. The token is only valid on the satellite cluster for a certain amount of time (which I think defaults to 5m) before in needs to be re-validated. To get the true expiration time requires contacting the upstream cluster. It seems like controller isn't doing that, and neither is workbench.

Note that the Rails upgrade in progress on #22608 touches some of this code so there's a risk of merge conflicts if both are in development at once.

22228-separate-expire-and-refresh @ d06efdb70673c4ae66bc6122e29a09416f703fd2 -- developer-run-tests: #4703

• All agreed upon points are implemented / addressed. Describe changes from pre-implementation design.
  • ✅ add internal column refreshes_at
  • ✅ if refreshes_at is in the past, token is not accepted
  • ✅ when caching a remote token, the cache assigns refreshes_at, and preserves the upstream expires_at
  • ✅ when auto-deleting expired tokens, we also delete tokens with refreshes_at < now (in a separate statement, to make sure postgresql doesn't skip the indexes)
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • n/a
• Code is tested and passing, both automated and manual, what manual testing was done is described.
  • ✅ existing tests updated to use refreshes_at to "uncache"
  • ✅ new test to check the OP issue is solved, i.e., expires_at is the value from upstream
• New or changed UX/UX and has gotten feedback from stakeholders.
  • n/a
• Documentation has been updated.
  • n/a
• Behaves appropriately at the intended scale (describe intended scale).
  • no anticipated scaling issues
• Considered backwards and forwards compatibility issues between client and server.
  • n/a - clients don't see the new field, they just see less-confusing values in the expires_at field
• Follows our coding standards and GUI style guidelines.
  • ✅

This LGTM, thanks!