You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When invoking an S3 Object Lambda across accounts the UserIdentity is not properly deserialized leading to the following error:
ERROR Lambda runtime invoke{requestId="c9df1aeb-b25a-45e1-a5c1-10177dfd07fa" xrayTraceId="Root=1-689e6efc-5075bf990965516e59d1c1d3;Parent=27b597d95d56f96c;Sampled=0;Lineage=1:f7613759:0"}: Request payload deserialization into LambdaEvent<T> failed. The handler will not be called. Log at TRACE level to see the payload. error=DeserializeError { inner: Error { path: Path { segments: [Map { key: "userIdentity" }] }, original: Error("missing field `principalId`", line: 1, column: 3595) } }
The payload looks something like the following (redactedness aside)
TRACE Lambda runtime invoke{requestId="e08b9d4d-8292-4195-8ca7-25779882919c" xrayTraceId="Root=1-689e7254-2add7ba14f84da2d7d6177f5;Parent=309c1bcabb60e983;Sampled=0;Lineage=1:f7613759:0"}: raw JSON event received from Lambda body="{\"xAmzRequestId\":\"cfffd328-cef7-48dd-82c3-e2022d8198d0\",\"getObjectContext\":{\"outputRoute\":\"io-cell001\",\"outputToken\":\"REDACTED\",\"inputS3Url\":\"https://REDACTED_ACCESS_POINT?X-Amz-Security-Token=MORE-REDACTED-STUFF&X-Amz-SignedHeaders=host%3Bx-amz-checksum-mode&X-Amz-Expires=61&X-Amz-Credential=SUCHREDACT&X-Amz-Signature=SOCONFIDENTL\"},\"configuration\":{\"accessPointArn\":\"arn:aws:s3-object-lambda:us-east-2:POOF:REDACTO_ACCESSO\",\"supportingAccessPointArn\":\"arn:aws:s3:us-east-2:POOF:REDACTO_ACCESSO\",\"payload\":\"\"},\"userRequest\":{\"url\":\"https://REDACTED_RESMACTED\",\"headers\":{\"x-amz-checksum-mode\":\"ENABLED\",\"Accept\":\"*/*\",\"Host\":\"DOMO_ARIGATO_MISTER_REDACTO\",\"amz-sdk-invocation-id\":\"b51434e8-3081-4b69-85db-e7772e7fc6fd\",\"amz-sdk-request\":\"ttl=20250814T233439Z; attempt=2; max=5\",\"Accept-Encoding\":\"identity\",\"X-Amz-Content-SHA256\":\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\"}},\"userIdentity\":{\"type\":\"AWSService\",\"invokedBy\":\"\"},\"protocolVersion\":\"1.00\"}"
I struggled to find documentation on what the expected UserIdentity contents might look like for variations of Lambda invocations, but the simple fix was to make a somewhat copy of S3ObjectLambdaEvent without a bunch of the fields, as my use-case only requires GetrObjectContext
I think the fix here is to make principalId an Option<String> but I would hope that somebody from AWS would be able to get a clearer picture of what the UserIdentity options might be
Based on that guide, it looks like the userIdentity structure in S3 Object Lambda events follows the same format as CloudTrail’s userIdentity. In that documentation, principalId is explicitly marked as Optional: True, so it may not always be present in the event.
This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
Activity
46ki75 commentedon Sep 10, 2025
I found the documentation for the event that S3 Object Lambda sends to a Lambda function here:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/olap-event-context.html
This page references the AWS CloudTrail User Guide for the
userIdentityfield:https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html
Based on that guide, it looks like the
userIdentitystructure in S3 Object Lambda events follows the same format as CloudTrail’suserIdentity. In that documentation,principalIdis explicitly marked as Optional: True, so it may not always be present in the event.jlizen commentedon Apr 2, 2026
Changing it to
Option<String>seems reasonable to me. It is clearly null sometimes, which means that the current behavior is buggy.So, the breaking change is unfortunate but seems justifiable.
A more conservative option would be to use the new
deserialize_nullishhelper added in #1130 .I'd be ok with either, personally, but happy to ping somebody in the lambda team to weigh in about correctness if anybody wants to work on this.
rtyler commentedon Apr 4, 2026
tbh since ObjectLambda is toast, there's no point here 😄
github-actions commentedon Apr 4, 2026
This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.