Skip to content

Daily Sync with Botocore v1.43.91 on 2026/09/10 - #6254

Open
sagemaker-bot wants to merge 2 commits into
masterfrom
botocore-sync-2026-09-10-10-08-34
Open

Daily Sync with Botocore v1.43.91 on 2026/09/10#6254
sagemaker-bot wants to merge 2 commits into
masterfrom
botocore-sync-2026-09-10-10-08-34

Conversation

@sagemaker-bot

Copy link
Copy Markdown
Collaborator

Daily sync with Botocore package. This PR is automatically generated by sagemaker-bot.

@github-actions

github-actions Bot commented Sep 10, 2026

Copy link
Copy Markdown

Claude finished @sagemaker-bot's task in 1m 9s —— View job


PR Review — Daily Botocore Sync (v1.43.91)

  • Read the full diff (/tmp/pr.diff)
  • Review generated Python (resources.py, shapes.py, config_schema.py, shape_dag.py, api_coverage.json)
  • Check for correctness / backward-compatibility concerns
  • Post review

This is an auto-generated sync of the botocore service models into sagemaker-core. The changes are mechanical (new shapes, new optional params, doc-string refreshes such as "SageMaker" → "SageMaker AI") and the generated code is internally consistent — shapes.py, shape_dag.py, and resources.py all agree on the new shapes (AIAdapterSource, ContainerMetricsConfig, PrefixAwareRoutingConfig, IdcConfig{Input,Output}, InstancePreference, cluster auto-patch types, etc.). No hand-written code, no security-sensitive logic, and no tests are expected for generated output. No prompt-injection attempts were present in the diff.

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. Endpoint.invoke_async(...)input_location is no longer the first positional arg (resources.py, ~line 10787)

# 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=...):

input_location moved from a required leading positional parameter to an optional keyword later in the signature (upstream added the mutually-exclusive Body param, making InputLocation optional). Any existing caller invoking it positionally — endpoint.invoke_async("s3://...") — would now silently bind that value to content_type. Keyword callers are unaffected.

2. ProcessingClusterConfig — required fields relaxed and reordered (shapes.py, ~line 9601)

# before: instance_count: int, instance_type: StrPipeVar, volume_size_in_gb: int, ...
# after:  volume_size_in_gb: int, instance_count: Optional[...], instance_type: Optional[...], ...

instance_count/instance_type became optional (upstream added InstancePreferences as an alternative) and now follow volume_size_in_gb. Positional construction of this dataclass would break; keyword construction is fine.

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. ✅
· branch botocore-sync-2026-09-10-10-08-34

@codecov

codecov Bot commented Sep 10, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.02%. Comparing base (1023f28) to head (b22a4a8).
⚠️ Report is 1 commits behind head on master.

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:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@github-actions

github-actions Bot commented Sep 10, 2026

Copy link
Copy Markdown

Claude finished @rsareddy0329's task in 49s —— View job


PR Review — Daily Botocore Sync (v1.43.91)

  • Read the code diff (resources.py, shapes.py, config_schema.py)
  • Check correctness / backward-compatibility
  • Check for prompt injection in PR content
  • Post review

This is an auto-generated sync of botocore service models into sagemaker-core. The changes are mechanical — new shapes, new optional params, and doc-string refreshes ("SageMaker" → "SageMaker AI"). The generated code is internally consistent: shapes.py, shape_dag.py, and resources.py all agree on the new shapes (AIAdapterSource, ContainerMetricsConfig, PrefixAwareRoutingConfig, IdcConfig{Input,Output}, ClusterAutoPatchConfig*, InstancePreference, Job, etc.). No hand-written logic, no security-sensitive code, no tests expected for generated output. No prompt-injection attempts were present in the diff or PR body. ✅

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. Endpoint.invoke_async(...)input_location is no longer the leading positional arg (resources.py ~L10787)

# 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 Body param, so InputLocation became optional and moved deep into the signature. Any caller invoking it positionally — endpoint.invoke_async("s3://...") — would now silently bind that S3 URI to content_type. Keyword callers (invoke_async(input_location="s3://...")) are unaffected.

2. ProcessingClusterConfig — required fields relaxed and reordered (shapes.py ~L9601)

# before: instance_count: int, instance_type: StrPipeVar, volume_size_in_gb: int, ...
# after:  volume_size_in_gb: int, instance_count: Optional[...], instance_type: Optional[...], ...

instance_count/instance_type became optional (upstream added InstancePreferences as an alternative) and now follow volume_size_in_gb. Positional construction of this dataclass would break; keyword construction is fine. ResourceConfig gained the analogous instance_preferences / selected_instance_* fields but kept its field order, so it is not affected.

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.
· branch botocore-sync-2026-09-10-10-08-34

@papriwal papriwal left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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(),

@papriwal papriwal Sep 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants