[BUG] node.forEach is not a function when using .filter().contains() on [String] field

[smundro]

Summary:

Model includes a string array field, with the test data being an array with a single string, attempting to filter query using contains results in a node.forEach is not a function error. Other issue mentioned removing the "default" value, but not using a default here.

Code sample:

Schema

 KeySchema:
                    - AttributeName: "announcementId"
                      KeyType: "HASH"

Model

{
    announcementId: { type: String, hashKey: true, required: true },
    announcementText: String,
    unitIds: { type: Array, schema: [String] },
    deleted: Number,
}

General

AnnouncementModel.filter('deleted').not().exists().filter('unitIds').contains(unitId).all().exec() // fails
AnnouncementModel.filter('deleted').not().exists().all().exec() // succeeds

Current output and behavior (including stack trace):

Error in query TypeError: node.forEach is not a function
at .webpack/handler.js:142378:22
at Array.forEach ()
at traverse (.webpack/handler.js:142372:31)
at .webpack/handler.js:142389:17
at Array.forEach ()
at traverse (.webpack/handler.js:142372:31)
at Function.Item.attributesWithSchema (.webpack/handler.js:142395:5)
at .webpack/handler.js:142561:43
at Array.map ()
at Function.Item.objectFromSchema (.webpack/handler.js:142560:46)
at Object.dynamoPropertyForAttribute (.webpack/handler.js:143127:40)
at utils_1.default.async_reduce (.webpack/handler.js:141677:95)
at .webpack/handler.js:146393:16
at runMicrotasks ()
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Object.default_1 [as async_reduce] (.webpack/handler.js:146391:20)
at async Object.requestObject (.webpack/handler.js:141751:60)
at async Query.ItemRetriever.getRequest (.webpack/handler.js:142823:52)
at async .webpack/handler.js:142805:32
at async getAnnouncements (.webpack/handler.js:242371:21)

Expected output and behavior:

Expecting .filter('[string array field]').contains('string') to work

Environment:

Operating System: serverless-offline 8.8.1 Lambda
Operating System Version:
Node.js version (node -v): 16.18
NPM version: (npm -v): yarn 1.22
Dynamoose version: 3.2.0

Other information (if applicable):

Worked fine in Dynamoose v2, issue appeared in Dynamoose v3

Other:

• I have read through the Dynamoose documentation before posting this issue
• I have searched through the GitHub issues (including closed issues) and pull requests to ensure this issue has not already been raised before
• I have searched the internet and Stack Overflow to ensure this issue hasn't been raised or answered before
• I have tested the code provided and am confident it doesn't work as intended
• I have filled out all fields above
• I am running the latest version of Dynamoose

[zachitzcovitch]

Same here, node seems to have a value of true, so forEach clearly won't work.
Optionally calling the forEach with node.forEach?. seems to fix the issue and the query works properly but I don't know the implications of doing this & won't be using it, just some info I found while exploring that can hopefully help with the direction of this issue.

[zachitzcovitch]

To add more context, it seems querying/scanning any array is broken

[Anhdao153]

Same here, node seems have value of true or undefined. Then node.forEach got errors.

[adback03]

Anyone find a workaround for this? Not being able to query on arrays is a pretty big bug...

I decided to store my data slightly different to get around this bug...one of my fields I wanted was an arbitrary array of 1 word string values. I was originally storing it in a string array, but decided to change it to a comma delimited string. Now when I want to search on multiple tags, like find my document where tags contains X or Y or Z, I did something like this:

let query = myModel.query('myKey').eq('myVal');
let categories = ['one','two']
let condition = new Condition();
categories.forEach((value) => {
  condition = condition.or().where('categories').contains(value);
});
query = query.parenthesis(condition);

This gets the desired results on my end, although not preferred.

[ziolmar]

+1

[lehafari]

• 1