SNOW-2324060 don't attempt non working bucket accelerate endpoint for internal stages #2556
Conversation
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
sfc-gh-dszmolka
added
the
DO_NOT_PORT_CHANGES_TO_SP
sfc-gh-dszmolka
requested review from
a team,
sfc-gh-fpawlowski and
sfc-gh-pczajka
…low the previous checks to complete
…-accelerate-endpoint
…-accelerate-endpoint
sfc-gh-pczajka
approved these changes
Oct 3, 2025
…-accelerate-endpoint
sfc-gh-dszmolka
deleted the
SNOW-2324060-dont-attempt-non-working-bucket-accelerate-endpoint
branch
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Description
This is hopefully an end to a multi-year story. Please see the full history in the (sorry!) internal jira, but the short version is that the necessary permission
s3:GetAccelerateConfiguration-on purpose- is missing from the Snowflake AWS role which is assumed during storage operations on Snowflake internal stages.Without this permission, the initial
/acceleratecall to the bucket endpoint will be unsuccessful in 100% of the time.This call to the transfer acceleration endpoint was always there as far as I can tell; and never seen it working in the past years. So out from the two possible approaches (either grant the permission, or remove the call) this is the second, after confirming internally we don't want to do the first ;)
The 'error' had no actual business impact besides logging a logline with HTTP response code 403 and maybe spending a little time on the
/acceleratecall; the rest of the operations (PUT, GET, etc) were always successfully performed.But why spend any time and resources on a call which we know for a fact will be always unsuccessful?
This PR aims to address this situation. Also a tiny bit more of logging around the operation.