Daily Sync with Botocore v1.43.91 on 2026/09/10 - #6254
Conversation
|
Claude finished @sagemaker-bot's task in 1m 9s —— View job PR Review — Daily Botocore Sync (v1.43.91)
This is an auto-generated sync of the botocore service models into Two things are worth calling out to downstream consumers — both faithfully reflect upstream API changes rather than generator bugs, so they're informational, not blockers: 1. # before
def invoke_async(self, input_location: StrPipeVar, content_type=..., ...):
# after
def invoke_async(self, content_type=..., accept=..., custom_attributes=...,
inference_id=..., input_location: Optional[StrPipeVar] = Unassigned(), ..., body=...):
2. # before: instance_count: int, instance_type: StrPipeVar, volume_size_in_gb: int, ...
# after: volume_size_in_gb: int, instance_count: Optional[...], instance_type: Optional[...], ...
Neither is actionable within this sync — they're driven by the AWS API model. Flagging only so the release notes / consumers are aware of the positional-argument shift. Otherwise the PR looks clean. ✅ |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #6254 +/- ##
==========================================
+ Coverage 70.92% 71.02% +0.09%
==========================================
Files 553 553
Lines 68089 68223 +134
==========================================
+ Hits 48295 48457 +162
+ Misses 19794 19766 -28 🚀 New features to boost your workflow:
|
|
Claude finished @rsareddy0329's task in 49s —— View job PR Review — Daily Botocore Sync (v1.43.91)
This is an auto-generated sync of botocore service models into Two backward-compatibility items are worth flagging for release notes / downstream consumers. Both faithfully reflect upstream API model changes rather than generator bugs, so they are informational, not blockers — but they can break callers that pass arguments positionally. 1. # before
def invoke_async(self, input_location: StrPipeVar, content_type=..., ...):
# after
def invoke_async(self, content_type=..., accept=..., custom_attributes=...,
inference_id=..., input_location: Optional[StrPipeVar] = Unassigned(),
s3_output_path_extension=..., filename=..., ..., body=...):Upstream added a mutually-exclusive 2. # before: instance_count: int, instance_type: StrPipeVar, volume_size_in_gb: int, ...
# after: volume_size_in_gb: int, instance_count: Optional[...], instance_type: Optional[...], ...
Neither is actionable within this sync — they're driven by the AWS API model. Flagging only so consumers are aware of the positional-argument shift. Otherwise the PR looks clean. |
papriwal
left a comment
There was a problem hiding this comment.
One backward-compatibility issue found in the generated public API.
| accept: Optional[StrPipeVar] = Unassigned(), | ||
| custom_attributes: Optional[StrPipeVar] = Unassigned(), | ||
| inference_id: Optional[StrPipeVar] = Unassigned(), | ||
| input_location: Optional[StrPipeVar] = Unassigned(), |
There was a problem hiding this comment.
Since this is a bot-generated sync, we should hold off merging this version until the generated API preserves backward compatibility. Model updates can legitimately change requiredness, but generated Python signatures still need careful review because positional ordering is part of the public SDK contract.
invoke_async previously took input_location as its first required positional parameter. This sync makes it optional and moves it behind content_type, accept, custom_attributes, and inference_id. An existing call such as endpoint.invoke_async("s3://bucket/input.json") would therefore bind the URI to content_type and leave input_location unset, silently breaking existing callers.
Could we preserve compatibility by either adding a generator customization that keeps input_location first while defaulting it to Unassigned(), or retaining the previous public signature in a compatibility wrapper that maps its arguments into the new request shape?
Daily sync with Botocore package. This PR is automatically generated by sagemaker-bot.