src/Adapters/Storage/Mongo/MongoSchemaCollection.js (4)

54-55:Optional: add field context to the error for easier debugging

If we keep throwing insidemongoFieldToParseSchemaField, wrapping this call to appendclassName/fieldName context improves operator UX when boot fails on bad schemas.

-    obj[fieldName] = mongoFieldToParseSchemaField(schema[fieldName]);+    try {+      obj[fieldName] = mongoFieldToParseSchemaField(schema[fieldName]);+    } catch (e) {+      if (e && e.code != null) {+        // Preserve code; enrich message+        e.message = `Invalid field type for "${fieldName}" in class "${schema._id}": ${e.message}`;+      }+      throw e;+    }

---

5-11:Add regression tests for non-string/whitespace input types

To lock this down, please add tests covering:

• type: undefined, null, number, boolean, object, array, function
• type: '' and ' ' (whitespace)
• type: 'number ' (trailing space) → with the trim change, should map to Number; without it, it silently fails

If helpful, I can draft a spec inspec/schemas.spec.js that exercisesmongoSchemaFieldsToParseSchemaFields with a mocked schema input.

---

25-47:Add a default case inmongoFieldToParseSchemaField to reject unsupported types

I’ve confirmed that the only call site formongoFieldToParseSchemaField is withinmongoSchemaFieldsToParseSchemaFields, and no code relies on it returningundefined. Failing fast on unrecognized types will surface schema misconfigurations immediately without breaking existing behavior.

• File:src/Adapters/Storage/Mongo/MongoSchemaCollection.js
• Location: inside theswitch (type) inmongoFieldToParseSchemaField

Recommended diff:

   switch (type) {     // …existing cases…     case 'polygon':       return { type: 'Polygon' };+    default:+      throw new Parse.Error(+        Parse.Error.INVALID_SCHEMA_OPERATION,+        `Unsupported field type: "${type}".`+      );   }

---

5-13:Tighten type validation and normalize input

Great addition to guard againstTypeError. Two optional hardening tweaks:

• Reject empty or whitespace-only strings by usingtype.trim().
• Trimtype before downstream checks so trailing (or leading) spaces can’t sneak through.

Proposed diff in src/Adapters/Storage/Mongo/MongoSchemaCollection.js (lines 5–13):

   // Add type validation to prevent TypeError-  if (!type || typeof type !== 'string') {+  if (typeof type !== 'string' || type.trim() === '') {     throw new Parse.Error(       Parse.Error.INVALID_SCHEMA_OPERATION,-      `Invalid field type: ${type}. Expected a string. Field type must be one of: string, number, boolean, date, map, object, array, geopoint, file, bytes, polygon, or a valid relation/pointer format.`+      `Invalid field type: ${String(type)}. Expected a non-empty string. Field type must be one of: string, number, boolean, date, map, object, array, geopoint, file, bytes, polygon, or a valid relation/pointer format.`     );   }++  // Normalize input+  type = type.trim();

Follow-up question:

• All other “invalid field type” guards (e.g. in SchemaController) useParse.Error.INCORRECT_TYPE. Should we switch fromINVALID_SCHEMA_OPERATION toINCORRECT_TYPE here for consistency?

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

spec/MongoSchemaCollectionAdapter.spec.js (2)

3-3:Align Parse import with repo convention to ensureParse.Error is available

Other specs importParse via.Parse; this avoids ambiguity with the module export shape and is consistent across the repo.

-const Parse = require('parse/node');+const Parse = require('parse/node').Parse;

---

101-131:Good coverage of valid type mappings

The table-driven checks for string/number/boolean/date/object/array/geo/file/bytes/polygon/pointer/relation look solid.

Optional: add role-based cases to catch regressions around special classes.

       const testCases = [         { input: 'string', expected: { type: 'String' } },@@         { input: 'relation<_User>', expected: { type: 'Relation', targetClass: '_User' } },         { input: 'relation<Post>', expected: { type: 'Relation', targetClass: 'Post' } },+        { input: '*_Role', expected: { type: 'Pointer', targetClass: '_Role' } },+        { input: 'relation<_Role>', expected: { type: 'Relation', targetClass: '_Role' } },       ];

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: RahulLanjewar93PR: parse-community/parse-server#9744File: spec/ParseLiveQuery.spec.js:0-0Timestamp: 2025-04-30T19:31:35.344ZLearning: In the Parse Server codebase, the functions in QueryTools.js are typically tested through end-to-end behavior tests rather than direct unit tests, even though the functions are exported from the module.

Learnt from: mtrezzaPR: parse-community/parse-server#9445File: spec/ParseLiveQuery.spec.js:1312-1338Timestamp: 2025-05-04T20:41:05.147ZLearning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`.

Learnt from: mtrezzaPR: parse-community/parse-server#9445File: spec/ParseLiveQuery.spec.js:1340-1375Timestamp: 2025-05-09T09:59:06.289ZLearning: Tests in the parse-server repository should use promise-based approaches rather than callback patterns with `done()`. Use a pattern where a Promise is created that resolves when the event occurs, then await that promise.

src/Adapters/Storage/Mongo/MongoSchemaCollection.js (2)

25-47:Fail fast on unknown string types (optional but safer)

Right now unknown strings fall through and returnundefined, which may propagate subtly. Consider throwing to surface bad data early. Backward-compat risk is low if such values are already invalid.

Apply:

     case 'polygon':       return { type: 'Polygon' };+    default:+      throw new Parse.Error(+        Parse.Error.INVALID_SCHEMA_OPERATION,+        `Unsupported field type: '${type}' for field '${fieldName}' in class '${className}'.`+      );

---

4-12:Apply: coerce invalid type to readable string and report class name

Search found only this occurrence of INVALID_SCHEMA_OPERATION in src; change is localized—apply the diff below.

-  if (!type || typeof type !== 'string') {-    throw new Parse.Error(-      Parse.Error.INVALID_SCHEMA_OPERATION,-      `Invalid field type: ${type} for field '${fieldName}' in class '_SCHEMA' (id: ${className}). Expected a string. Fix the type mismatch in your schema configuration.`-    );-  }+  if (!type || typeof type !== 'string') {+    const received = typeof type === 'undefined' ? 'undefined' : String(type);+    throw new Parse.Error(+      Parse.Error.INVALID_SCHEMA_OPERATION,+      `Invalid field type: ${received} for field '${fieldName}' in class '${className}'. Expected a string. Fix the type mismatch in your schema configuration.`+    );+  }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro