bharos opened a new pull request, #15999: URL: https://github.com/apache/iceberg/pull/15999
### What Fix child `AuthSession` inheriting the parent session's `expiresAtMillis` instead of computing it from its own token. ### Why When creating a child `AuthSession` via `fromTokenResponse()` or `fromAccessToken()`, the `AuthConfig` builder calls `.from(parent.config())` to inherit configuration (scope, credential, oauth2ServerUri, etc.). However, Immutables' `from()` copies **all** values from the parent, including `expiresAtMillis`. This overrides the `@Value.Default` method that would otherwise recompute the expiry from the child's own JWT `exp` claim. **Impact**: The child session schedules its first token refresh based on the **parent's** token expiry, not its own. In token exchange flows where: - Catalog session holds a long-lived token (e.g., 1-hour Azure AD token) - Exchanged per-user token is short-lived (e.g., 5-minute token) ...the refresh is scheduled ~54 minutes out instead of ~4.5 minutes, causing the short-lived token to expire without being refreshed. ### How Explicitly set `expiresAtMillis` from the child token in both `fromTokenResponse()` and `fromAccessToken()` builders: ```java .expiresAtMillis(OAuth2Util.expiresAtMillis(response.token())) ``` This ensures the child session's expiry is always derived from its own token's JWT `exp` claim (or `null` for opaque tokens, falling back to `response.expiresInSeconds()` for scheduling). ### Testing Added 3 tests to `TestOAuth2Util`: - `fromTokenResponseUsesChildTokenExpiry` — verifies child JWT token's exp is used, not parent's - `fromTokenResponseOpaqueTokenDoesNotInheritParentExpiry` — verifies opaque child tokens don't inherit parent's exp - `fromAccessTokenUsesChildTokenExpiry` — verifies the same fix for `fromAccessToken()` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
