Update all dependencies and fix examples

[s0l0ist]

📬 Issue #, if available:

• N/A

✍️ Description of changes:

• Prunes unused dependencies in the workspace
• Update all dependencies the examples via cargo upgrade and cargo update
  • Fixed examples with the latest dependencies that caused them to break
  • Pruned unused dependencies via cargo machete --with-metadata
  • Formatted via cargo +nightly fmt
  • Clippy via cargo clippy --fix

All tests/examples compile and pass. I have not tested e2e integration and was hoping CI would cover that path.

🔏 By submitting this pull request

• I confirm that I've ran cargo +nightly fmt.
• I confirm that I've ran cargo clippy --fix.
• I confirm that I've made a best effort attempt to update all relevant documentation.
• I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jlizen]

Hi @s0l0ist , thanks for your work on this!

It makes sense to me to bump the crates that have newer major versions (if >=1.x) or minor versions (0.x) since that will help simplify consumer dependency graphs and let us benefit from new features. I see you did some legwork to migrate some of the apis, such as for the aws sdk dependencies, which is awesome.

Likewise the cargo machete usage is great, pleased to see us rip out some larger dependencies like tokio from some of the workspace crates.

However I'm not sold on the bumps to pre-1.0 patch versions, and post-1.0 minor versions. Since, anyway consumers are resolving to the latest version that their closure allows, but moving forward the floor might create headaches for consumers that need to pin back to an older dependency version for some reason (as then they need to pin us as well).

Would it be possible to leave those types of version bumps out unless there is a new API or feature we specifically want in the newest semver compatible version?

Glad to discuss it further if there is an angle I'm missing here. The main downside I'm aware of is accidentally using features that are dependent on newer nonbreaking versions - but we could add ci validations with cargo update -Zdirect-minimal-versions if that becomes a problem.

[s0l0ist]

Hi @jlizen, thanks for your feedback!

I agree with you on not bumping the floor unnecessarily. I've reverted the version changes to workspace dependencies where applicable. There's now only the two dev-deps that have been bumped: axum-core and axum-extra.

However, I chose not to revert the changes in the examples directory. There doesn't appear to be a consistent convention for how dependencies are specified there - I found a mix of major, major.minor, and major.minor.patch versions across different examples. In many cases, I noticed examples referencing older versions of lambda-runtime instead of using a local path = "../../lambda-runtime" (and other related packages to this workspace) which makes consistency more difficult to enforce.

Since these examples are meant to be illustrative (not consumed directly as libraries), I believe it's reasonable for them to track the latest compatible versions. This makes them easier to maintain and helps users see working, up-to-date code. In most cases, users would copy the examples and manage their own dependencies independently of the workspace anyway.

Let me know if you'd prefer a different approach, but my recommendation is to keep the version bumps in the examples for now.

(I also ran clippy and +nightly fmt which updated a few misc things)

[jlizen]

I've reverted the version changes to workspace dependencies where applicable

Thanks!

There's now only the two dev-deps that have been bumped

Seems fine, dev-dependencies are harmless to keep fresh.

However, I chose not to revert the changes in the examples directory.

I agree with this choice, good call.

I'll give the changes a deeper read through today to get you a full review!

[jlizen]

Looks great! Thanks again for the cleanup.

[jlizen]

Ooh, this was a good machete ❤️

[jlizen]

Two more great ones

[jlizen]

Wow, this too. I guess anyway most consumers would be pulling them in via sibling dependencies, but still.