chore: release

[darklight3it]

🤖 New release

• lambda-extension: 1.0.2 -> 1.0.3 (✓ API compatible changes)
• lambda_runtime: 1.1.0-rc1 -> 1.1.0-rc1.1 (✓ API compatible changes)
• lambda_http: 1.1.0-rc1 -> 1.1.0-rc1.1 (✓ API compatible changes)
• aws_lambda_events: 1.1.0 -> 1.1.1

Changelog

lambda-extension

1.0.3 - 2026-03-12

Other

• Make Telemetry API log record type generic (#1098)

lambda_runtime

1.1.0-rc1.1 - 2026-03-12

Added

• (lambda-runtime) log non-2xx Lambda Runtime API responses with status and body (#1109)

Fixed

• (test) fix test_concurrent_structured_logging_isolation (#1121)

Other

• Introducing Harness Testing (#1103)
• add tokio_unstable to known cfgs to avoid linter warns
• (lambda-managed-instances) warn on run() with `AWS_LAMBDA_MAX_CONCURRENCY, rename feature experimental-concurrency -> concurrency->tokio
• Add builder pattern support for event response types (#1090)
• verify request-ID isolation in concurrent exec (#1086)

lambda_http

1.1.0-rc1.1 - 2026-03-12

Other

• (lambda-managed-instances) warn on run() with `AWS_LAMBDA_MAX_CONCURRENCY, rename feature experimental-concurrency -> concurrency->tokio
• disable default features of lambda-runtime (#1093)
• (deps) update axum-extra requirement from 0.10.2 to 0.12.5 (#1079)

aws_lambda_events

1.1.1 - 2026-03-12

Other

• updated the following local packages: lambda_runtime

---

This PR was generated with release-plz.

[jlizen]

@darklight3it looks like we will need to manually bump out of rcs?

[darklight3it]

@darklight3it looks like we will need to manually bump out of rcs?

I am looking into it, I don't know yet. release-plz created an RC version but I think I can modify this PR to and it will work.

[darklight3it]

Now it works. I think we are good to go. Let's review the release notes and add some thanks.

[jlizen]

This configuration will work, but it will result in separate github release entries (and changelog filesies) per crate. We might consider instead grouping all of the other crate releases into the lambda-runtime release. reference config. That is perhaps a bit more conventional.

Though, we do release lambda-events (and other crates) somewhat distinct from lambda-runtime, so it could go either way. Up to you.

[jlizen]

might be nice to call out #1063 as well

[darklight3it]

added in events.

[jlizen]

this was #1095 though IDK if it merits a mention, I think these were selectively curated?

[jlizen]

also #1095

[jlizen]

#1095

[darklight3it]

This configuration will work, but it will result in separate github release entries (and changelog filesies) per crate. We might consider instead grouping all of the other crate releases into the lambda-runtime release. reference config. That is perhaps a bit more conventional.

Though, we do release lambda-events (and other crates) somewhat distinct from lambda-runtime, so it could go either way. Up to you.

Looking at the past its seems we did only one release body for everything. I would go in that direction.

[bnusunny]

Are we bump to v1.1.1?

[jlizen]

Ah yeah a bunch of rcs still, good catch. Release-plz doesn't make it easy to go off...