Skip to content

B5/api token refresh#76

Draft
b5 wants to merge 22 commits intomainfrom
b5/api_token_refresh
Draft

B5/api token refresh#76
b5 wants to merge 22 commits intomainfrom
b5/api_token_refresh

Conversation

@b5
Copy link
Copy Markdown
Member

@b5 b5 commented Apr 8, 2026

Description

Breaking Changes

Notes & open questions

Change checklist

  • Self-review.
  • Documentation updates following the style guide, if relevant.
  • Tests if relevant.
  • All breaking changes documented.

okdistribute and others added 22 commits March 23, 2026 16:00
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
I think this should be "label" to help call out that uniqueness is not
enforced by the server.

I've also picked an arbitrary max length & enforced it client-side, which
affects the signature, because setting the label can now fail.
because auth is non-exhaustive now
running both versions at the same time is a no-go. This uses an
additive approach that will work in both contexts.
Add a refresh timer to ClientActor that proactively requests a new
capability token from the server before the current one expires.

Refresh schedule:
- >72h remaining: refresh at the halfway point of remaining lifetime
- ≤72h remaining: refresh hourly
- Very short-lived tokens: refresh at remaining/2 (minimum 1s)
- Already expired: refresh immediately

Includes a mock server test that verifies the full refresh cycle
with a 4-second token.
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