Recursion check in toObject breaks mongoose-intl plugin

[yelworc]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Mongoose version

=6.3.5

Node.js version

=18

MongoDB server version

7

Typescript version (if applicable)

No response

Description

As of Mongoose v6.3.5, the mongoose-intl plugin does not work anymore when used in subdocument arrays. Calling toJSON or toObject with getters enabled on such objects results in an error.

In order to narrow down the source of the problem, I recreated what the plugin is doing in a standalone gist. The behavior and the resulting error is the same as my actual issue with mongoose-intl in a closed-source production system.

The changes in commit 8325e563 are what introduced the problem; specifically, the recursion checking seen map will cache and return subdocuments where the getters for localized string fields have already been applied (e.g. {field: 'some text'}), but then the toObject mechanism tries to clone the single-language schema paths (like field.en), which conflicts with the already present field value.

Now, I realize that mongoose-intl is doing something fishy here with its virtuals that Mongoose wouldn't normally allow (having a "real" field.xyz schema path and a field virtual) 😄. However, it might be relatively easy to work around; changing

branch[part] = clone(val, options);

to

if (utils.isObject(branch)) branch[part] = clone(val, options);

in document/applyGetters fixes the problem (and a similar change might be necessary in document/applyVirtuals) – but of course that might entail unintended side effects.

If you consider this a bug (resp. invalid behavior) in mongoose-intl, I'd be grateful for any ideas for fixing it there; preferably in ways that wouldn't require a DB migration 😄

Steps to Reproduce

See the gist; if it helps, I could also provide sample code that is using mongoose-intl.

Expected Behavior

No response

[yelworc]

Many thanks for the quick fix, @vkarpov15!

Is this change going to propagate to 7.x and 8.x/master, eventually (I've seen past commits like Merge branch '7.x' in the log)? If not, the problem is likely going to pop up again once we try to update 😄

[vkarpov15]

Yep, we merge 6.x into 7.x and 7.x into master periodically