Skip to content

Conversation

joe4dev
Copy link
Member

@joe4dev joe4dev commented Jun 17, 2025

Motivation

Ruby transparent endpoint injection tests fail due to a change in the RUBYLIB variable. The official AWS Docker images do not match what we observe in AWS Lambda.

Changes

@joe4dev joe4dev added this to the 4.6 milestone Jun 17, 2025
@joe4dev joe4dev self-assigned this Jun 17, 2025
@joe4dev joe4dev added the semver: patch Non-breaking changes which can be included in patch releases label Jun 17, 2025
Copy link

Test Results - Preflight, Unit

21 621 tests  ±0   19 964 ✅ ±0   6m 20s ⏱️ -15s
     1 suites ±0    1 657 💤 ±0 
     1 files   ±0        0 ❌ ±0 

Results for commit b4aed3e. ± Comparison against base commit 21c4d5d.

Copy link

Test Results (amd64) - Acceptance

7 tests  ±0   5 ✅ ±0   3m 16s ⏱️ -1s
1 suites ±0   2 💤 ±0 
1 files   ±0   0 ❌ ±0 

Results for commit b4aed3e. ± Comparison against base commit 21c4d5d.

Copy link

Test Results - Alternative Providers

987 tests   589 ✅  30m 14s ⏱️
  4 suites  398 💤
  4 files      0 ❌

Results for commit b4aed3e.

Copy link

Test Results (amd64) - Integration, Bootstrap

    5 files      5 suites   1h 51m 47s ⏱️
3 689 tests 3 017 ✅ 672 💤 0 ❌
3 695 runs  3 017 ✅ 678 💤 0 ❌

Results for commit b4aed3e.

Copy link

LocalStack Community integration with Pro

    2 files      2 suites   1h 20m 18s ⏱️
3 665 tests 2 990 ✅ 675 💤 0 ❌
3 667 runs  2 990 ✅ 677 💤 0 ❌

Results for commit b4aed3e.

Copy link
Contributor

@gregfurman gregfurman left a comment

Choose a reason for hiding this comment

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

LGTM!

We should probably look at improving our transformations of these envars going forward (especially since we don't set them). I'm concerned we're a bit too at the mercy of random variables changing and breaking our pipelines 🤦

@@ -549,21 +549,21 @@
"AWS_LAMBDA_INITIALIZATION_TYPE": "on-demand",
"AWS_LAMBDA_LOG_GROUP_NAME": "/aws/lambda/<function-name:1>",
"AWS_LAMBDA_LOG_STREAM_NAME": "<log-stream-name:1>",
"AWS_LAMBDA_RUNTIME_API": "127.0.0.1:9001",
"AWS_LAMBDA_RUNTIME_API": "169.254.100.1:9001",
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we not be transforming this IP address? The same applies to a couple of these other variables:

AWS_XRAY_DAEMON_ADDRESS
_AWS_XRAY_DAEMON_ADDRESS

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think we should transform these unless the value becomes dynamic. They seem stable, and having them raw allows us to detect upstream changes that may have other implications.

Example:

# Changed from 127.0.0.1:9001 to 169.254.100.1:9001 around 2024-11, which would require network changes

@gregfurman
Copy link
Contributor

FYI, think this is the commit aws/aws-lambda-base-images@8c4c659 that introduced these changes. Seems like new layers were being added and Dockerfiles updated?

Could be worth setting up some internal monitoring for when these branches are pushed to 👀

@gregfurman gregfurman marked this pull request as ready for review June 17, 2025 11:47
@gregfurman gregfurman merged commit 7f02575 into master Jun 17, 2025
43 checks passed
@gregfurman gregfurman deleted the fix/update-lambda-runtime-snapshots branch June 17, 2025 11:47
@joe4dev
Copy link
Member Author

joe4dev commented Jun 17, 2025

LGTM!

We should probably look at improving our transformations of these envars going forward (especially since we don't set them). I'm concerned we're a bit too at the mercy of random variables changing and breaking our pipelines 🤦

Good point. I added an item to our next Lambda service owner sync 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver: patch Non-breaking changes which can be included in patch releases
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants