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
In previous versions of the aws-sdk (specifically @aws-sdk/lib-dynamodb), the default behaviour when providing undefined values to DynamoDb PUT operations was to throw an exception with the message Pass options.removeUndefinedValues=true to remove undefined values from map/array/set.. This was the equivalent behaviour of initialising the DB Client with removeUndefinedValues: false.
Since release 3.429.0, this is no longer the case - undefined values provided to DynamoDb operations are instead just removed, which is the equivalent of removeUndefinedValues: true. Manually setting removeUndefinedValues: false has no effect.
I believe this has been caused by this change which was included as a bug fix for release 3.429.0.
Details of the browser/Node.js/ReactNative version
v20.14.0
Reproduction Steps
Running the below code in @aws-sdk/[email protected] and below will fail with error message Pass options.removeUndefinedValues=true to remove undefined values from map/array/set..
Running the below code in @aws-sdk/[email protected] and above will succeed, removing the undefined attributes.
In @aws-sdk/[email protected] and below, this operation would throw an exception with the error message Pass options.removeUndefinedValues=true to remove undefined values from map/array/set., unless removeUndefinedValues: true is set in the DynamoDb instance config.
In @aws-sdk/[email protected] and above, the operation will succeed, and will have removed the undefined values from the record altogether - regardless of the removeUndefinedValues setting.
Expected Behavior
I would expect the behaviour to be consistent - that the operation would throw an exception with the error message Pass options.removeUndefinedValues=true to remove undefined values from map/array/set., unless removeUndefinedValues: true is set in the DynamoDb instance config.
Possible Solution
No response
Additional Information/Context
No response
The text was updated successfully, but these errors were encountered:
peteraiken
changed the title
DynamoDb no longer throwing an exception for undefined attributes (and removeUndefinedValues being ignored)
DynamoDb no longer throwing an exception for undefined attributes on PUT (and removeUndefinedValues being ignored)
Sep 4, 2024
The behavior you're observing is actually the expected and intended behavior. Previously, the users were running into TypeError (in this issue) until the PR you mentioned corrected the behavior. As explained in the PR, the previous behavior was incorrect because an undefined column in a DynamoDB row is not the same as an undefined member in a map or set. An undefined column cannot be resolved to any specific AttributeValue type.
The fix implemented in the PR was to support top-level undefined AttributeValues and also validate nested values appropriately. This change ensures that undefined columns are handled correctly, aligning with the expected behavior of the DynamoDB service.
You can also refer to this comment by our team member from previous issue.
Let us know if you have further questions.
Best,
John
aBurmeseDev
added
response-requested
Waiting on additional info and feedback. Will move to \"closing-soon\" in 7 days.
p3
This is a minor priority issue
and removed
needs-triage
This issue or PR still needs to be triaged.
labels
Sep 7, 2024
Thanks @aBurmeseDev - I appreciate this is definitely smoother behaviour, I raised it for us because we had some functionality that we intentionally wanted to fail if a value was undefined and on upgrading the package, this stopped happening. Of course we can get around this by adding our own null checks before the operation, but good to know this is an intentional change.
Just to clarify - does this mean that removeUndefinedValues now only applies (and should only apply) to internal properties of maps/sets, and not to top-level attributes?
Checkboxes for prior research
Describe the bug
In previous versions of the aws-sdk (specifically
@aws-sdk/lib-dynamodb
), the default behaviour when providingundefined
values to DynamoDbPUT
operations was to throw an exception with the messagePass options.removeUndefinedValues=true to remove undefined values from map/array/set.
. This was the equivalent behaviour of initialising the DB Client withremoveUndefinedValues: false
.Since release 3.429.0, this is no longer the case -
undefined
values provided to DynamoDb operations are instead just removed, which is the equivalent ofremoveUndefinedValues: true
. Manually settingremoveUndefinedValues: false
has no effect.I believe this has been caused by this change which was included as a bug fix for release 3.429.0.
SDK version number
@aws-sdk/[email protected]
Which JavaScript Runtime is this issue in?
Node.js
Details of the browser/Node.js/ReactNative version
v20.14.0
Reproduction Steps
Running the below code in
@aws-sdk/[email protected]
and below will fail with error messagePass options.removeUndefinedValues=true to remove undefined values from map/array/set.
.Running the below code in
@aws-sdk/[email protected]
and above will succeed, removing the undefined attributes.Observed Behavior
In
@aws-sdk/[email protected]
and below, this operation would throw an exception with the error messagePass options.removeUndefinedValues=true to remove undefined values from map/array/set.
, unlessremoveUndefinedValues: true
is set in the DynamoDb instance config.In
@aws-sdk/[email protected]
and above, the operation will succeed, and will have removed the undefined values from the record altogether - regardless of theremoveUndefinedValues
setting.Expected Behavior
I would expect the behaviour to be consistent - that the operation would throw an exception with the error message
Pass options.removeUndefinedValues=true to remove undefined values from map/array/set.
, unlessremoveUndefinedValues: true
is set in the DynamoDb instance config.Possible Solution
No response
Additional Information/Context
No response
The text was updated successfully, but these errors were encountered: