Skip to content

[Internal] Implement async token refresh #893

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 24, 2025

Conversation

hectorcast-db
Copy link
Contributor

@hectorcast-db hectorcast-db commented Feb 19, 2025

What changes are proposed in this pull request?

This PR is a step towards enabling asynchronous refreshes of data plane tokens.
This PR updates the existing Refreshable abstract token class to support async token refresh.

Note: async refreshes are disabled at the moment and will be enabled in a follow-up PR.

How is this tested?

Added unit tests.

Changelog

The changelog entry will be added when the feature is enabled.

NO_CHANGELOG=true

Copy link
Contributor

@renaudhartert-db renaudhartert-db left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me overall.

As discussed offline, the first version had a problem with the ThreadPoolExecutor being created when the class was loaded. This is fixed now.

Comment on lines 248 to 250
token_state = self._token_state()

with self._lock:
token = self._token
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we release the lock here, the token on line 251 could be different than the one used in _token_state(). If we convert _token_state() to something that returns the token and its state, we can avoid that problem. Thoughts?

self._is_refreshing = False

with self._lock:
if not self._is_refreshing and not self._refresh_err:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is safe but might fetch more tokens than necessary. Like you mentioned offline, the first thread to acquire this lock will start the refresh process, and then all other threads that acquire the lock while refresh is happening will skip. However, once refresh is complete, other threads that acquire the lock (e.g. that checked that the token was stale and came down this pathway while the refresh was ongoing, then only acquired this lock after refresh was completed) will unnecessarily refresh the token again. So I think we should also check the token state again here: if it is not stale, skip the refresh.

@hectorcast-db hectorcast-db force-pushed the hectorcast-db/stale-token branch from 11c42a2 to 21c999f Compare February 21, 2025 11:39
Copy link
Contributor

@mgyucht mgyucht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks good to me!

Copy link

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/sdk-py

Inputs:

  • PR number: 893
  • Commit SHA: d3ffe7968de23f88dcb07c774eabad12b1baa05e

Checks will be approved automatically on success.

@hectorcast-db hectorcast-db added this pull request to the merge queue Feb 24, 2025
Merged via the queue into main with commit e550ca1 Feb 24, 2025
19 of 20 checks passed
@hectorcast-db hectorcast-db deleted the hectorcast-db/stale-token branch February 24, 2025 07:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants