Include params set in provide-client-param event handlers in dynamic context params for endpoint resolution#2920
Conversation
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## develop #2920 +/- ##
===========================================
- Coverage 93.44% 93.41% -0.04%
===========================================
Files 63 63
Lines 13551 13572 +21
===========================================
+ Hits 12663 12678 +15
- Misses 888 894 +6
☔ View full report in Codecov by Sentry. |
dlm6693
left a comment
There was a problem hiding this comment.
Just a couple of stylistic comments, but otherwise LGTM!
| api_params = self._emit_api_params( | ||
| api_params=api_params, | ||
| operation_model=operation_model, | ||
| context=request_context, | ||
| ) |
There was a problem hiding this comment.
Maybe this could be called from within _resolve_endpoint_ruleset at the very start of it? I'm thinking in purely organizational terms just because _make_api_call is a rather long, complex function already.
| ignore_signing_region=(not bucket_is_arn), | ||
| ) | ||
|
|
||
| params = self._emit_api_params( |
There was a problem hiding this comment.
The only concern I have with this PR is we're moving this into multiple places now making any future changes harder to keep consistent.
It would be nice to keep these consolidated with _convert_to_request_dict, but I don't see an immediate solution for that.
There was a problem hiding this comment.
I think using my suggestion of putting this in _resolve_endpoint_ruleset would accomplish that no?
There was a problem hiding this comment.
Or does this still need to happen immediately after endpoint resolution for presigned URLs?
|
@dlm6693 @nateprewitt Added two commits that consolidate the previously duplicated code. This comes at the cost of a change to the API of the While making this change I also fixed the presign functions which were actually still affected by the original bug and added test coverage for this oversight. |
|
After reviewing potential impact of the API change contained in bd44524, @nateprewitt and I decided to revert to the less well organized state that has been discussed above. Note that f8e01a6 is not an exact line-for-line revert because it keeps the bugfix described in #2920 (comment). |
This reverts commit bd44524.
f8e01a6 to
878cd84
Compare
|
@jonemo still LGTM after the latest commit 👍 |
* release-1.29.133: Bumping version to 1.29.133 Update to latest partitions and endpoints Update to latest models Update black formatting Include params set in provide-client-param event handlers in dynamic context params for endpoint resolution (#2920) Addresses admonition accessibility issue (#2928) Update pre-commit hooks versions
Emit `provide-client-params.*` and `before-parameter-build.*` before endpoint resolution. This ports the following botocore pull request: boto/botocore#2920 One update to the endpoint name in the test_signers.py unit test was applied to use the region name in the s3 endpoint, consistent with existing CLI v2 tests.
Emit `provide-client-params.*` and `before-parameter-build.*` before endpoint resolution. This ports the following botocore pull request: boto/botocore#2920 One update to the endpoint name in the test_signers.py unit test was applied to use the region name in the s3 endpoint, consistent with existing CLI v2 tests.
This PR moves the
provide-client-params.*andbefore-parameter-build.*from immediately after endpoint resolution to immediately before endpoint resolution.This addresses the fact that for endpoint rulesets that accept dynamic context parameters (currently
s3,s3-control,kinesis, andevents) any parameters changed or updated in an event handler for theprovide-client-params.*were not accounted for in endpoint resolution because the event was only emitted after endpoint resolution.