Skip to content

fix: parse MiniMax OAuth expired_in as unix-ms timestamp not TTL seconds#21786

Closed
rexliu1912-star wants to merge 1 commit into
NousResearch:mainfrom
rexliu1912-star:fix/minimax-oauth-expired-in-timestamp
Closed

fix: parse MiniMax OAuth expired_in as unix-ms timestamp not TTL seconds#21786
rexliu1912-star wants to merge 1 commit into
NousResearch:mainfrom
rexliu1912-star:fix/minimax-oauth-expired-in-timestamp

Conversation

@rexliu1912-star

Copy link
Copy Markdown

Problem

MiniMax OAuth returns expired_in as a unix millisecond timestamp (absolute time, e.g. 1746729600000), not a relative TTL in seconds.

hermes_cli/auth.py was treating it as seconds and adding it to now.timestamp(), producing a timestamp in year ~58381, causing Python's datetime to overflow with:

Login failed: year 58381 is out of range

Fix

  1. Login path (_minimax_oauth_login, L4876): detect whether expired_in > 1_000_000_000_000 (millisecond unix timestamp) and divide accordingly.

  2. Refresh path (_refresh_minimax_oauth_state, L4960): same logic applied to the refresh response.

  3. Refresh skew bumped from 60s to 86400s (1 day) so tokens are refreshed proactively.

Testing

Manual: hermes auth add minimax-oauth now succeeds and stores correct expires_at; auto-refresh fires 24h before expiry instead of 60s before.

No test suite change required as this fixes a production-only edge case with real OAuth tokens.

MiniMax returns expired_in as a unix millisecond timestamp (absolute time),
not a relative TTL in seconds. The old code treated it as seconds, causing
datetime overflow (year ~58381) when computing expires_at.

Also bump MINIMAX_OAUTH_REFRESH_SKEW_SECONDS from 60s to 86400s (1 day)
so tokens are refreshed proactively before expiry.
@alt-glitch alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard provider/minimax MiniMax (Anthropic transport) area/auth Authentication, OAuth, credential pools P3 Low — cosmetic, nice to have duplicate This issue or pull request already exists labels May 8, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Duplicate of #20374 which fixes the same MiniMax OAuth expired_in unix-ms timestamp issue (and also addresses the authorization URL domain). See also #20106 for another overlapping fix.

@teknium1

Copy link
Copy Markdown
Contributor

Closing as superseded by #24165.

Triage notes (high confidence):
main hermes_cli/auth.py:6883 already has _minimax_resolve_token_expiry_unix handling unix-ms vs TTL, used at lines 7018,7096 by login/refresh. Landed via merged PR #24165 (fix(minimax): harden OAuth dashboard and runtime, 2026-05-12).

Thanks for the contribution — the underlying problem this PR addresses has been resolved by the linked PR on current main. If you believe this was closed in error, please comment and we'll reopen.

(Bulk-closed during a CLI PR triage sweep.)

@teknium1 teknium1 closed this May 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/auth Authentication, OAuth, credential pools comp/cli CLI entry point, hermes_cli/, setup wizard duplicate This issue or pull request already exists P3 Low — cosmetic, nice to have provider/minimax MiniMax (Anthropic transport) type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants