You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While running FastMCP's stored-token expiry tests on Windows, I observed intermittent failures with expires_in=0: the client sometimes reused the stored token instead of acquiring a fresh one.
I reproduced the behavior in isolated environments using MCP SDK 2.3.0 alone and FastMCP 4.1.1 with MCP SDK 2.3.0.
OAuthContext.is_token_valid() returns True when the current time exactly equals token_expiry_time, because it uses <=. Once the clock advances past that timestamp, it correctly returns False. The same equality behavior occurs with a normal 3600-second token checked exactly at expiry.
I expected the token to be invalid at its expiration timestamp. Could you confirm whether the inclusive boundary is intentional, or whether it should be considered expired at equality?
The observed impact is intermittent downstream test failures, not a demonstrated production authentication failure. The example below uses a fixed nonzero clock to make the boundary deterministic; it needs no network or real credentials.
Prepared with AI assistance; the reproductions were executed locally and reviewed before submission.
Windows
Python 3.12.15
MCP SDK 2.3.0
Pydantic 2.14.1
Also reproduced through FastMCP 4.1.1's client-credentials auth flow
with MCP SDK 2.3.0 in a separate environment.
Activity