Repository navigation
Conversation
## Motivation `S3Presigner` built a new S3 Express auth scheme, with its own empty session cache, on every presign call. Each presign for a directory bucket therefore made its own blocking `CreateSession` call and started a background refresh that nothing ever stopped, because `S3Presigner.close()` only closed the credentials provider. A long-running application that presigns S3 Express URLs leaked one refresh loop per presign call and sent growing `CreateSession` traffic. ## Changes 1. Each presigner now creates its auth schemes once, so all of its presign calls share one S3 Express session cache. 2. Repeated presigns for the same bucket and credentials reuse one session, with one `CreateSession` call and one refresh loop. 3. `S3Presigner.close()` now closes that cache, which cancels every background refresh it started, and it still closes the credentials provider if closing the cache fails. 4. The cache keeps its limit of 25 entries, and evicted entries are closed. 5. Add a bugfix changelog entry for Amazon S3. ## Compatibility 1. Presigned URLs for one bucket now carry the same session token until the cached session refreshes, where before each URL carried a token from a fresh `CreateSession` call. 2. A presign call made after `close()`, or concurrently with it, can still add a cache entry whose refresh is never closed, because there is no closed-state check. 3. `S3Client` keeps its current behavior on `close()`, with a cache bounded at 25 entries per client. ## Testing A new unit test class uses a mocked `S3Client` whose `CreateSession` returns credentials that expire about 62 seconds out, so a background refresh fires within a few seconds. Four tests cover the change: - Four presigns of one directory bucket call `CreateSession` once, and the URL contains a session token. - Two buckets presigned twice each call `CreateSession` twice. - Without `close()`, the refresh calls `CreateSession` at least twice within 6 seconds. - After `close()`, `CreateSession` is still called only once after 6 seconds. Against the old code, three of the four fail. The existing presigner and S3 Express tests pass. ## Alternatives Considered 1. Close the per-call cache at the end of each presign. Every presign would still make a blocking `CreateSession` call and discard the session. 2. Reuse the session cache of the presigner's `S3Client`. The client does not expose its auth schemes, and the presigner would use a cache it does not own. 3. Use one cache shared by all presigners in the process. Nothing would own it to close it, and its key would mix presigners that differ only by client. 4. Switch presigner caches to a strategy without background refresh. That changes refresh behavior shared with the client and still makes one `CreateSession` call per presign.
davidh44
reviewed
Oct 30, 2026
- Call CreateSession directly on every presign, with no cache - Add UncachedS3ExpressAuthScheme for the presigner - Extract static createSession in S3ExpressIdentityCache - Revert close support in S3 Express cache and auth scheme - Rewrite presigner S3 Express test for uncached behavior - Update changelog entry
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
S3Presignerbuilt a new S3 Express auth scheme, with its own empty session cache, on every presign call. Each presign for a directory bucket made a blockingCreateSessioncall and started a background refresh that nothing ever stopped. A long-running application that presigns S3 Express URLs leaked one refresh loop per presign call and sent growingCreateSessiontraffic.Changes
UncachedS3ExpressAuthScheme, an internal S3 Express auth scheme whose identity provider callsCreateSessionon every identity resolution, with no cache and no background refresh.S3Presigneruses this scheme for directory buckets, so a presign call leaves nothing running after it returns.S3ExpressIdentityCacheinto a staticcreateSession(key)so both paths share it.Compatibility
CreateSessioncall, the same as before, so URLs keep the full session lifetime (about 5 minutes).CreateSessioncall. This matches the current behavior.S3Clientand its session cache are unchanged.Testing
A new unit test class uses a mocked
S3ClientwhoseCreateSessionreturns a distinct token each call, with credentials that expire about 62 seconds out. A cached session would refresh in the background within a few seconds. Two tests cover the change:CreateSessionthree times, and each URL carries its own session token.CreateSessioncall happens within 6 seconds.The existing presigner and S3 Express unit tests pass.
Alternatives Considered
S3Presigner.close(). This fixes the leak, but presigns reuse a cached session until it refreshes about 60 seconds before it expires. A URL could then be valid for only about a minute, or about 15 seconds if the background refresh is skipped, even whensignatureDurationasks for more.CreateSessioncost as this change, but it still builds a cache and schedules a refresh only to cancel it.S3Client. The client does not expose its auth schemes, and the presigner would use a cache it does not own.