-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Open
Labels
type:bugImpaired feature or lacking behavior that is likely assumedImpaired feature or lacking behavior that is likely assumed
Description
New Issue Checklist
- Report security issues confidentially.
- Any contribution is under this license.
- Before posting search existing issues.
Issue Description
Since transformInteriorValue 4d43614, the code never trigger the logics after value !== CannotTransform
. This bug was noticed and fixed in #8209 in a wrong way, and later #8446 introduced a (partially) corrected but duplicated fix.
Steps to reproduce
Actual Outcome
Expected Outcome
Environment
Server
- Parse Server version:
7.4.0
- Operating system:
Ubuntu
- Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc):
AWS
Database
- System (MongoDB or Postgres):
MongoDB
- Database version:
5.0.18
- Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc):
AWS
Client
- SDK (iOS, Android, JavaScript, PHP, Unity, etc):
JavaScript
- SDK version:
5.3.0
Logs
Metadata
Metadata
Assignees
Labels
type:bugImpaired feature or lacking behavior that is likely assumedImpaired feature or lacking behavior that is likely assumed
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
parse-github-assistant commentedon Jan 22, 2025
Thanks for opening this issue!
mtrezza commentedon Jan 22, 2025
Is this a bug, or just a code refactoring without any effects on performance or behavior?
kassiansun commentedon Jan 22, 2025
I didn't test it, but I think the RegExp and Bytes are all broken since #8446, because
if (value && typeof value === 'object') {
will be true for both, so the value saved in database will be a JSON-serialized version ofmongodb.Bytes
andmongodb.RegExp
(or not broken ifmapValues(restValue, transformInteriorValue)
doesn't change the value of the object, but this is a coincidence instead of an explicit specified behavior).Also this logic is handled properly after #9566, which is a definitely a behavior change (although it's from the original refactoring, but it never triggered since that):
mtrezza commentedon Jan 23, 2025
Ok, we keep this classified as a bug. Could you please make sure the PR contains a test that demonstrates the issue?