[brmur]

This pull request restores the Rust CI (Lint Rust) job, which is currently failing on every PR that touches rustv1/** because the AWS SDK for Rust crates raised their MSRV past the pinned CI toolchain.

Why

Lint Rust pins rustc 1.88.0, but the current aws-config / aws-sdk-* / aws-smithy-* crates now require 1.94.1, so cargo clippy/test fail at dependency resolution for all four Rust workspaces. (The repo intentionally gitignores Cargo.lock, so resolution always floats to the latest crates.)

What changed

Followed the maintenance procedure documented in rustv1/README.md:

1. Bump the toolchain to 1.94.1 via rustv1/tools/set_rust_version.py 1.94.1, which updates .github/workflows/lint-rust.yml and both rust-toolchain.toml channels in sync with the SDK MSRV.
2. Resolve the clippy findings that 1.94.1 newly surfaces under -D warnings in pre-existing examples (cargo clippy --fix plus manual fixes):
   • cross_service/photo_asset_management: drop unused/elided lifetimes
   • examples/eks/create-cluster: fix doc list item overindentation
   • examples/iam/hello: box the large SdkError variant (result_large_err)
   • examples/testing: #[allow(dead_code)] on a documentation fake struct
3. Pin the webassembly workspace's AWS deps to the pre-http 1.x generation. aws-smithy-runtime-api >= 1.8 dropped the TryFrom<http 0.2 Response> impl in favor of http 1.x, which breaks aws-wasm's custom HTTP adapter. Capping aws-config/aws-sdk-lambda/aws-smithy-* avoids migrating the wasm adapter; resolves to aws-smithy-runtime-api 1.7.3 / http 0.2.12.

Ran WRITEME for Rust afterward — no README changes were required (the lint fixes did not shift any snippet anchors).

Verification

cargo clippy --all (with RUSTFLAGS="-D warnings") and cargo fmt --all --check pass on all four workspaces (cross_service, examples, lambda, webassembly) with the 1.94.1 toolchain, matching the CI job's format + lint steps.

All Rust examples across all four workspaces now compile and lint cleanly on the corrected toolchain, and their unit test suites compile; the subset of tests that don't require live AWS pass.

This should be merged before the Bedrock sample PRs (#8204, #8205, #8206), which currently fail Lint Rust for this same pre-existing reason.

Related: internal ticket V2245921888.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

🤖 AI Code Example Review

This PR is a well-scoped maintenance update that restores a broken Rust CI pipeline by bumping the toolchain to 1.94.1 and addressing the resulting lint/dependency failures. All changes are minimal, targeted, and correct — this should pass review.

Detailed Review

1. [nit] rustv1/webassembly/Cargo.toml: The version range >=1.1, <1.2 for aws-config is very narrow (only the 1.1.x patch series). Given that AWS SDK crates follow a rapid release cadence, this tight upper bound may need revisiting sooner than expected. A comment explaining why the cap sits below 1.2 (i.e., the http 0.2 vs 1.x TryFrom breakage) would help future maintainers avoid accidentally widening it.

2. [nit] rustv1/webassembly/Cargo.toml: Similarly, the range for aws-sdk-lambda (>=1.3, <1.20) has a wider upper bound than the smithy crates (<1.8, <1.3). If aws-sdk-lambda 1.19 pulls in an incompatible aws-smithy-runtime-api, Cargo will still resolve within the declared range and could surface a runtime breakage. Ideally the caps would be tightened consistently, or the PR description's rationale (aws-smithy-runtime-api 1.7.3) would be encoded as a pinned version comment.

3. [nit] rustv1/examples/iam/src/bin/hello.rs: Returning Box<SdkError<...>> from main silences the result_large_err lint but makes the error output slightly less readable for end-users (the Debug impl for Box<E> delegates to E, so it's functionally fine). An alternative would be a newtype or a String conversion, but boxing is an accepted idiom here and consistent with how the SDK docs handle this.

4. [nit] rustv1/cross_service/photo_asset_management/src/handlers/detect_labels.rs: The async function detect_record previously carried a spurious 'a lifetime that was elided. The removal is correct. However, the parameters bucket: &String and object: &String would be more idiomatic as bucket: &str / object: &str — this is a pre-existing issue unrelated to the PR, so it's a nit rather than blocking.

5. [nit] rustv1/examples/testing/src/traits.rs: The #[allow(dead_code)] is placed on the struct. The fields expected_bucket, expected_prefix, and pages are still read within impl ListObjects for TestListObjects, so the lint most likely fires only because TestListObjects::new (a constructor) is absent and the struct is only instantiated via struct literals in tests. The attribute is correct and the comment // Demonstration fake used by the documentation snippet. is a nice touch that explains the intent.

6. [policy] No new tests are added, which is appropriate — this PR only fixes existing lint/toolchain issues rather than adding new functionality. The existing tests in detect_labels.rs and traits.rs are unchanged and continue to cover the modified code.

7. [nit] rustv1/cross_service/rust-toolchain.toml jumps from 1.87.0 to 1.94.1, skipping intermediate versions. The PR description explains the version was already one step behind (1.88.0 in CI vs 1.87.0 in toml) before this PR. Going forward it would be cleaner to keep both files in sync, but this is a pre-existing skew that this PR resolves.

8. [nit] The webassembly workspace does not appear to have its own rust-toolchain.toml updated (only cross_service and examples are updated). Since the wasm workspace intentionally pins older AWS crates, this may be intentional — a brief comment in the PR or the toml itself would clarify whether the wasm workspace is expected to run under a different channel.

9. [policy] The PR description mentions that cargo clippy --all and cargo fmt --all --check were verified locally across all four workspaces. Since the CI job was the exact thing being fixed, it is important that this PR itself triggers the Lint Rust job on the PR branch; the reviewer should confirm the CI badge is green before merging.

10. [nit] rustv1/examples/eks/src/bin/create-cluster.rs already has a file-level #![allow(clippy::result_large_err)] but also has #[allow(clippy::result_large_err)] on main. The doc indentation fix is the actual change here; the duplicate allow attributes are pre-existing and unrelated to this PR.

---

_{Reviewed at commit 39cb37923d13f3403642c0830eb5f651d6831200. This review was generated automatically using Amazon Bedrock. It compares your changes against existing examples and coding guidelines. Findings are labeled by severity (blocking / nit / policy) and reflect only the commit above. Please use your judgment — this is advisory, not authoritative.}

[brmur]

Updated per Rust team feedback:

1. webassembly → http 1.x (replaces the earlier dependency pin). Bumped http from 0.2 to 1; the http::Response builder API is unchanged across 0.2→1.x, so no changes to aws-wasm's lib.rs were needed — it was effectively a no-op, as predicted. The aws-* deps return to their original unpinned versions.
2. Committed Cargo.lock files. Removed Cargo.lock from rustv1/.gitignore and committed a lockfile per workspace (cross_service, examples, lambda, webassembly). This addresses the root cause of the recurring MSRV drift — unpinned resolution floating to the latest crates — so future dependency/MSRV changes become explicit reviewed diffs.

Verified: cargo clippy --locked --all (-D warnings) and cargo fmt --check pass on all four workspaces on 1.94.1; wasm32 target builds clean.

[github-actions]

🤖 AI Code Example Review

This follow-up commit adds Cargo.lock files and removes the global Cargo.lock gitignore entry — a necessary companion to the toolchain/dependency changes from the prior commit. All previously raised nits remain valid but unchanged; no new blocking issues are introduced.

Detailed Review

1. [policy] The primary change in this commit is adding rustv1/cross_service/Cargo.lock (5615 lines) and removing Cargo.lock from rustv1/.gitignore. This is a significant policy shift: the repo previously intentionally gitignored lock files (per the PR description), but this commit checks one in. The PR description says 'The repo intentionally gitignores Cargo.lock', yet this commit contradicts that. A human reviewer should explicitly decide whether committing lock files is the new policy for all workspaces or just cross_service.

2. [nit] Only rustv1/cross_service/Cargo.lock is added, but the .gitignore removal applies to all of rustv1/. This means examples/, lambda/, and webassembly/ workspaces will also no longer have their lock files ignored going forward, yet no lock files are committed for those workspaces. This asymmetry could lead to accidental lock file commits in those workspaces by contributors, or confusion about why they are not present. Consider either committing all four lock files or restoring the gitignore and adding per-workspace overrides.

3. [nit] The cross_service lock file resolves aws-smithy-runtime-api to 1.19.0 (visible in the lock), while the webassembly workspace intentionally caps it at <1.8 (from the prior commit). This is correct and expected per the PR description, but worth noting for reviewers: the two workspaces are intentionally on divergent SDK generations.

4. [nit] Previously raised concern about bucket: &String / object: &String in detect_labels.rs (prefer &str) is still present in the current code at lines ~55-57 of that file. This is pre-existing and unrelated to this PR's changes, so it remains a nit.

5. [nit] The rustv1/examples/eks/src/bin/create-cluster.rs file has both a file-level #![allow(clippy::result_large_err)] and a function-level #[allow(clippy::result_large_err)] on main. This duplicate allow is still present and pre-existing; the PR only touched the doc comment indentation in that file.

6. [policy] No lock files are committed for examples, lambda, or webassembly workspaces. If the intent is to stabilize CI by locking dependency resolution, all four workspaces should have committed lock files, otherwise only cross_service benefits from reproducible builds.

7. [nit] The committed Cargo.lock uses format version = 4, which requires Cargo 1.78+. This is consistent with the 1.94.1 toolchain pin, so it is fine — but worth noting that the lock file cannot be read by older Cargo versions if someone tries to use an older toolchain.

8. [policy] The prior review's suggestion to add an inline comment to webassembly/Cargo.toml explaining the <1.2 cap on aws-config (to help future maintainers) has not been addressed. This remains an open nit from the previous review cycle.

---

_{Reviewed at commit 17198ecc7faacbb008e85827917137f7d4880cb8. This review was generated automatically using Amazon Bedrock. It compares your changes against existing examples and coding guidelines. Findings are labeled by severity (blocking / nit / policy) and reflect only the commit above. Please use your judgment — this is advisory, not authoritative.}

[landonxjames]

All changes look good to me, thanks for keeping our examples updated!

[github-actions]

🤖 AI Code Example Review

This follow-up commit is a clean maintenance update. All previously raised nits remain valid but are pre-existing or stylistic; no new blocking issues are introduced. The commit correctly adds Cargo.lock files and removes the global gitignore entry, completing the toolchain bump work from the prior commit.

Detailed Review

1. [policy] The addition of Cargo.lock files to the repository (removing the global Cargo.lock entry from .gitignore) is the primary change in this commit. This is the correct companion step to the toolchain/dependency changes: pinning lock files ensures reproducible builds in CI and prevents silent dependency float. This is good practice.

2. [nit] Prior item (still present, not new): rustv1/cross_service/photo_asset_management/src/handlers/detect_labels.rs line ~54 — detect_record takes bucket: &String and object: &String. These would be more idiomatic as &str. This is pre-existing and unrelated to this commit's changes.

3. [nit] Prior item (still present, not new): rustv1/examples/iam/src/bin/hello.rs returns Box<SdkError<ListPoliciesError>> from main. Boxing is an accepted idiom here and functionally fine; a newtype or anyhow would be marginally more user-friendly but is not required.

4. [nit] The cross_service/Cargo.lock is 5,615 lines, covering many transitive dependencies (actix-web, bindgen, chrono, etc.). This is expected for a multi-crate workspace, but reviewers should be aware that future SDK bumps will require regenerating this file. A brief note in rustv1/README.md about how to regenerate the lock files after SDK updates would be helpful for future maintainers.

5. [nit] Prior item (addressed): The detect_record function's spurious 'a lifetime has been correctly removed in the prior commit and remains absent in the current code. This is resolved.

6. [nit] Prior item (addressed): The #[allow(dead_code)] placement on TestListObjects in traits.rs is correct and remains in place with the explanatory comment. This is resolved.

7. [policy] No new tests are added, which is appropriate — this PR only fixes toolchain/dependency/lock file issues rather than adding new functionality.

8. [nit] The Cargo.lock for cross_service resolves aws-smithy-runtime-api to 1.19.0 (visible in the lock file snippet), which is the latest generation using http 1.x. This is correct for the cross_service workspace. The webassembly workspace's lock file (not shown in this diff) should resolve to aws-smithy-runtime-api 1.7.3 as described in the PR. Reviewers should verify the webassembly/Cargo.lock is also committed and resolves to the capped versions.

9. [nit] Prior item (addressed): The rustv1/.gitignore previously removed Cargo.lock globally; this has been corrected by removing that line and committing the lock files per-workspace. This is the right approach.

10. [policy] The CI job (Lint Rust) is the primary thing being fixed. The reviewer should confirm the CI badge is green on this PR branch before merging, as noted in the prior review.

---

_{Reviewed at commit 8943e32885dbc0357b97d25edcd77dd61f45b388. This review was generated automatically using Amazon Bedrock. It compares your changes against existing examples and coding guidelines. Findings are labeled by severity (blocking / nit / policy) and reflect only the commit above. Please use your judgment — this is advisory, not authoritative.}