Conversation
|
@coderabbitai do code review , verify if the changes adhere to best practices and fail safe. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain@borkarsaish65, I'll review the changes in this PR for best practices and fail-safe mechanisms. Let me fetch the PR details first. 🏁 Script executed: Length of output: 4125 🏁 Script executed: Length of output: 3915 @borkarsaish65, I've completed the code review. Here are my findings with severity levels: 🚨 CRITICAL ISSUES1. Security Vulnerability: Debugger Exposed to All Network InterfacesFile: "dev": "node --inspect=0.0.0.0:9229 app.js"Issue: Using Fix: Change to localhost only: "dev": "node --inspect=127.0.0.1:9229 app.js"Or simply use: "dev": "node --inspect app.js"🐛 BUGS2. Function Signature MismatchFile: Issue: // Function accepts only 2 params
function handleStringType(key, values) {
// ...
}
// But called with 3 params
handleStringType(key, input[key], filterType) // filterType is ignored!Fix: Update the function signature and implement filterType logic: function handleStringType(key, values, filterType) {
const currentFilter = filterType[key]?.trim()?.toUpperCase() === 'OR' ? 'OR' : 'AND'
const conditions = values
.map((value, index) => {
replacements[`${key}_${index}`] = value
return `${key} = :${key}_${index}`
})
.join(` ${currentFilter} `)
queryParts.push(`(${conditions})`)
}
|
WalkthroughAdds per-entity filter semantics by deriving each entity's filterType (OR/AND) from metadata and threading it through filter construction and conversion, altering array-handling operators and exposing Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/generics/utils.js (1)
534-542: UnusedfilterTypeparameter passed tohandleStringType.At line 569,
filterTypeis passed tohandleStringType, but the function signature at line 534 only accepts(key, values). The third argument is silently ignored.Either update the signature to use
filterTypefor string-type filters (if OR semantics should apply), or remove the extra argument from the call site.If
filterTypeshould not affect string handling, apply this diff:if (common.ENTITY_TYPE_DATA_TYPES.STRING_TYPES.includes(dataType)) { - handleStringType(key, input[key], filterType) + handleStringType(key, input[key]) } else if (common.ENTITY_TYPE_DATA_TYPES.ARRAY_TYPES.includes(dataType)) {
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/generics/utils.js(5 hunks)src/package.json(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: sumanvpacewisdom
Repo: ELEVATE-Project/mentoring PR: 1426
File: src/database/migrations/20251020081719-add-orgEntity-type.js:10-12
Timestamp: 2025-11-06T06:25:57.830Z
Learning: In the ELEVATE-Project/mentoring repository, entity type migrations (like 20251020081719-add-orgEntity-type.js) run before tenant-specific migrations. Therefore, down migrations for these entity types do not need to filter by organization_code and tenant_code, as multi-tenant data does not exist at the time these migrations execute.
🔇 Additional comments (3)
src/generics/utils.js (3)
545-560: LGTM! Per-entity filter semantics correctly implemented.The PostgreSQL
&&(overlap/OR) and@>(contains/AND) operators are appropriately used based on the derivedfilterType. Minor note: line 553 re-normalizesfilterType[key]which is already normalized at line 527, but this is harmless.
737-746: LGTM! filterType propagation is consistent.The
filterTypederivation logic mirrorsvalidateAndBuildFilters, ensuring consistent OR/AND semantics across the filtering pipeline. The default to'AND'when metadata is absent maintains backward compatibility.
516-528: LGTM! Clean filterType dictionary initialization.The optional chaining with trim/toUpperCase normalization handles edge cases gracefully, and defaulting to
'AND'ensures backward-compatible behavior.
src/package.json
Outdated
| "prod": "NODE_ENV=production node app.js", | ||
| "stage": "NODE_ENV=stage node app.js", | ||
| "qa": "NODE_ENV=qa node app.js", | ||
| "dev": "node --inspect=0.0.0.0:9229 app.js", |
There was a problem hiding this comment.
Security concern: debugger bound to all network interfaces.
Binding --inspect=0.0.0.0:9229 exposes the Node.js debugger to all network interfaces. If this script is accidentally used in a non-local environment (e.g., a container with exposed ports), it could allow remote debugging access.
Additionally, unlike other scripts (start, prod, etc.), the dev script does not set NODE_ENV, which may cause unexpected behavior if the application relies on it.
Consider restricting to localhost and setting the environment:
- "dev": "node --inspect=0.0.0.0:9229 app.js",
+ "dev": "NODE_ENV=development node --inspect=127.0.0.1:9229 app.js",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "dev": "node --inspect=0.0.0.0:9229 app.js", | |
| "dev": "NODE_ENV=development node --inspect=127.0.0.1:9229 app.js", |
🤖 Prompt for AI Agents
In src/package.json around line 15, the dev script currently binds the Node
debugger to 0.0.0.0 and doesn't set NODE_ENV; update the script to restrict the
debugger to localhost and set NODE_ENV=development (e.g., use
NODE_ENV=development node --inspect=127.0.0.1:9229 app.js), and if Windows
cross-platform support is required, use cross-env to set NODE_ENV (e.g.,
cross-env NODE_ENV=development node --inspect=127.0.0.1:9229 app.js).
…into feature/3.3stories
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/generics/utils.js (1)
538-546: Critical bug: handleStringType ignores filterType parameter.The function
handleStringTypeis defined with only 2 parameters(key, values)at line 538, but is called with 3 parameters(key, input[key], filterType)at line 566. ThefilterTypeparameter is completely ignored, causing string-type entity filters to always use OR logic regardless of themeta.filterTypeconfiguration. This creates inconsistent behavior where array types respect the filterType but string types do not.🔎 Proposed fix
Update
handleStringTypeto accept and apply the filterType:// Function to handle string types -function handleStringType(key, values) { +function handleStringType(key, values, filterType) { + const operator = filterType[key] === 'OR' ? ' OR ' : ' AND ' const orConditions = values .map((value, index) => { replacements[`${key}_${index}`] = value return `${key} = :${key}_${index}` }) - .join(' OR ') + .join(operator) queryParts.push(`(${orConditions})`) }Also applies to: 566-566
🧹 Nitpick comments (3)
src/services/mentors.js (1)
87-109: Remove commented-out code.The commented-out implementation (lines 87-98) should be removed rather than retained. Commented code adds noise, makes the codebase harder to maintain, and can be retrieved from version control if needed.
🔎 Proposed cleanup
- - /* - let validationData = await entityTypeCache.getEntityTypesAndEntitiesWithCache( - { - status: common.ACTIVE_STATUS, - allow_filtering: true, - model_names: { [Op.contains]: [sessionModelName] }, - }, - tenantCode, - orgCode, - sessionModelName - ) - */ - let validationData = await entityTypeCache.getEntityTypesAndEntitiesForModel( sessionModelName, tenantCode, orgCode, { status: common.ACTIVE_STATUS, allow_filtering: true, - //model_names: { [Op.contains]: [sessionModelName] }, } )src/services/mentees.js (1)
1539-1559: Remove commented-out code.The commented-out implementation (lines 1539-1549) should be removed rather than retained. This follows the same pattern as in
mentors.jsand should be cleaned up for maintainability.🔎 Proposed cleanup
- /* - let validationData = await entityTypeCache.getEntityTypesAndEntitiesWithCache( - { - status: common.ACTIVE_STATUS, - model_names: { [Op.overlap]: [userExtensionModelName] }, - }, - tenantCode, - organizationCode, - userExtensionModelName - ) - */ - let validationData = await entityTypeCache.getEntityTypesAndEntitiesForModel( userExtensionModelName, tenantCode, organizationCode, { status: common.ACTIVE_STATUS, - //model_names: { [Op.overlap]: [userExtensionModelName] }, } )src/generics/utils.js (1)
111-113: Redundant filterType normalization.The
filterTypeis already normalized to 'OR' or 'AND' at lines 530-531 invalidateAndBuildFilters. This function re-normalizes withtrim().toUpperCase(), which is unnecessary.🔎 Proposed simplification
Since
filterType[key]is guaranteed to be either 'OR' or 'AND' from line 531, simplify to:const getArrayFilterOperator = (filterType, key) => { - return filterType[key]?.trim()?.toUpperCase() === 'OR' ? '&&' : '@>' + return filterType[key] === 'OR' ? '&&' : '@>' }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/generics/utils.jssrc/package.jsonsrc/services/mentees.jssrc/services/mentors.js
🚧 Files skipped from review as they are similar to previous changes (1)
- src/package.json
🧰 Additional context used
📓 Path-based instructions (1)
src/services/**
⚙️ CodeRabbit configuration file
This is core business logic. Please check for correctness, efficiency, and potential edge cases.
Files:
src/services/mentors.jssrc/services/mentees.js
🧠 Learnings (5)
📓 Common learnings
Learnt from: sumanvpacewisdom
Repo: ELEVATE-Project/mentoring PR: 1426
File: src/database/migrations/20251020081719-add-orgEntity-type.js:10-12
Timestamp: 2025-11-06T06:25:57.830Z
Learning: In the ELEVATE-Project/mentoring repository, entity type migrations (like 20251020081719-add-orgEntity-type.js) run before tenant-specific migrations. Therefore, down migrations for these entity types do not need to filter by organization_code and tenant_code, as multi-tenant data does not exist at the time these migrations execute.
📚 Learning: 2025-11-04T10:36:50.155Z
Learnt from: rakeshSgr
Repo: ELEVATE-Project/mentoring PR: 1442
File: src/services/sessions.js:1822-1831
Timestamp: 2025-11-04T10:36:50.155Z
Learning: In the ELEVATE-Project/mentoring codebase, when `mentorId` or `session.mentor_id` exist in the sessions service, the `mentorExtensionQueries.getMentorExtension()` call is guaranteed to return a valid object with a `name` property. Defensive null checks like `mentorDetails?.name` are not necessary when the mentor ID guard condition is present.
Applied to files:
src/services/mentors.js
📚 Learning: 2025-11-06T06:25:57.830Z
Learnt from: sumanvpacewisdom
Repo: ELEVATE-Project/mentoring PR: 1426
File: src/database/migrations/20251020081719-add-orgEntity-type.js:10-12
Timestamp: 2025-11-06T06:25:57.830Z
Learning: In the ELEVATE-Project/mentoring repository, entity type migrations (like 20251020081719-add-orgEntity-type.js) run before tenant-specific migrations. Therefore, down migrations for these entity types do not need to filter by organization_code and tenant_code, as multi-tenant data does not exist at the time these migrations execute.
Applied to files:
src/services/mentors.jssrc/services/mentees.js
📚 Learning: 2025-07-31T09:34:29.508Z
Learnt from: sumanvpacewisdom
Repo: ELEVATE-Project/mentoring PR: 1281
File: src/controllers/v1/connections.js:16-17
Timestamp: 2025-07-31T09:34:29.508Z
Learning: In the ELEVATE-Project/mentoring repository, validation for req.decodedToken fields (including tenant_code, organization_id, id, etc.) is not required in controller methods. The project handles token validation at a different layer and does not need additional validation checks in individual controller methods.
Applied to files:
src/services/mentors.js
📚 Learning: 2025-09-16T11:06:06.180Z
Learnt from: sumanvpacewisdom
Repo: ELEVATE-Project/mentoring PR: 1334
File: src/controllers/v1/entity-type.js:42-44
Timestamp: 2025-09-16T11:06:06.180Z
Learning: The entityTypeService.update method in src/services/entity-type.js has the signature: update(bodyData, id, loggedInUserId, orgCode, tenantCode, roles) - it includes the loggedInUserId parameter between id and orgCode.
Applied to files:
src/services/mentees.js
🧬 Code graph analysis (1)
src/services/mentees.js (1)
src/services/mentors.js (7)
validationData(100-109)validationData(478-478)validationData(585-585)validationData(1035-1035)validationData(1380-1385)entityTypeCache(13-13)common(4-4)
🔇 Additional comments (1)
src/generics/utils.js (1)
735-743: LGTM!The
convertEntitiesForFilterfunction correctly derives thefilterTypefrom entity metadata and includes it in the result object, ensuring consistency with the filtering logic invalidateAndBuildFilters.
|
@coderabbitai review the PR freshly , goal is to adhere to best coding practices and fail safe code |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 184311 @borkarsaish65, I've completed a fresh comprehensive review of PR #1502 focusing on best coding practices and fail-safe mechanisms. Here are my findings: 🚨 CRITICAL ISSUES1. Function Signature Mismatch - filterType Not Applied to String TypesFile: Issue: // Current implementation (WRONG)
function handleStringType(key, values) {
const orConditions = values
.map((value, index) => {
replacements[`${key}_${index}`] = value
return `${key} = :${key}_${index}`
})
.join(' OR ') // ❌ Always uses OR - ignores filterType
queryParts.push(`(${orConditions})`)
}
// Called with 3 params (line 569)
handleStringType(key, input[key], filterType) // ❌ filterType is ignored!Fix: function handleStringType(key, values, filterType) {
const currentFilter = filterType[key]?.trim()?.toUpperCase() === 'OR' ? 'OR' : 'AND'
const conditions = values
.map((value, index) => {
replacements[`${key}_${index}`] = value
return `${key} = :${key}_${index}`
})
.join(` ${currentFilter} `)
queryParts.push(`(${conditions})`)
}
|
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/generics/utils.js (1)
538-546: Critical: handleStringType ignores filterType parameter.The function is defined with only two parameters
(key, values)and hardcodes OR logic at line 544. This means string-type filters always use OR semantics regardless of thefilterTypemetadata, creating inconsistent behavior with array-type filters that correctly apply per-entity filter semantics.🔎 Proposed fix to accept and apply filterType
Update the function signature and implementation:
// Function to handle string types -function handleStringType(key, values) { - const orConditions = values +function handleStringType(key, values, filterType) { + const filter = normalizeFilterType(filterType) // assumes helper from earlier comment + const conditions = values .map((value, index) => { replacements[`${key}_${index}`] = value return `${key} = :${key}_${index}` }) - .join(' OR ') - queryParts.push(`(${orConditions})`) + .join(` ${filter} `) + queryParts.push(`(${conditions})`) }Then update the invocation at line 566:
if (common.ENTITY_TYPE_DATA_TYPES.STRING_TYPES.includes(dataType)) { - handleStringType(key, input[key]) + handleStringType(key, input[key], filterType[key]) } else if (common.ENTITY_TYPE_DATA_TYPES.ARRAY_TYPES.includes(dataType)) {Based on learnings from PR comments.
🧹 Nitpick comments (1)
src/generics/utils.js (1)
111-113: Extract filterType normalization into a reusable helper.The normalization pattern
filterType[key]?.trim()?.toUpperCase() === 'OR'is duplicated across multiple locations (here, line 530-531, and line 735). This violates DRY principles.🔎 Proposed refactor to centralize normalization
Add a helper function at the top of the filtering section:
+/** + * Normalizes filter type to 'OR' or 'AND' + * @param {string|undefined} filterType - Raw filter type value + * @returns {string} Normalized 'OR' or 'AND' + */ +function normalizeFilterType(filterType) { + return filterType?.trim()?.toUpperCase() === 'OR' ? 'OR' : 'AND' +} + const getArrayFilterOperator = (filterType, key) => { - return filterType[key]?.trim()?.toUpperCase() === 'OR' ? '&&' : '@>' + return normalizeFilterType(filterType[key]) === 'OR' ? '&&' : '@>' }Then update lines 530-531 and 735 to use this helper as well.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/generics/utils.js
🧰 Additional context used
🧬 Code graph analysis (1)
src/generics/utils.js (1)
src/helpers/search.js (1)
queryParts(171-182)
🔇 Additional comments (3)
src/generics/utils.js (3)
520-520: Safe default behavior for filterType.The initialization and normalization logic correctly defaults to 'AND' when filterType is not explicitly 'OR', which is a safe fail-safe behavior. The per-entity filterType map approach is sound.
Note: The normalization pattern here should also use the helper function suggested in the previous comment (lines 111-113).
Also applies to: 530-531
549-557: LGTM - Array type handling correctly applies filterType.The updated signature now accepts the
filterparameter and correctly applies it at line 556. The use of parameterized queries via thereplacementsobject properly mitigates SQL injection risks.
568-569: Correct invocation of array filtering with per-entity filterType.The code properly derives the array operator using
getArrayFilterOperatorand threads it through tohandleArrayType. This correctly implements per-entity OR/AND semantics for array types.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/generics/utils.js (1)
748-782: Consider adding JSDoc for this public API.The implementation correctly uses
getFilterTypeand includes thefilterTypefield in each returned object. However, the function lacks JSDoc documentation for its signature and return shape.Since this function's return shape now includes a new public field (
filterType), documenting it would help future developers understand the structure and purpose of this field.📝 Suggested JSDoc
+/** + * Converts entity types for filter usage, enriching with filter logic metadata + * @param {Array<Object>} entityTypes - Array of entity type objects with properties: + * - id, value, label, parent_id, organization_id + * - entities: Array of entity objects with value/label pairs + * - allow_custom_entities: Boolean indicating if custom values are allowed + * - meta.filterType: Optional filter logic ('OR' or 'AND') from metadata + * @returns {Object} Object keyed by entity type values, each containing an array of objects with: + * - id, label, value, parent_id, organization_id, entities + * - filterType: 'OR' or 'AND' - determines how multiple array values are combined: + * * 'OR': Match if ANY value matches (uses PostgreSQL && operator) + * * 'AND': Match if ALL values match (uses PostgreSQL @> operator) + * * Note: Only applies to array-type fields; string/scalar fields always use OR logic + */ function convertEntitiesForFilter(entityTypes) {This was requested in the previous review to document the new public API surface.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/generics/utils.js
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: borkarsaish65
Repo: ELEVATE-Project/mentoring PR: 1502
File: src/generics/utils.js:0-0
Timestamp: 2025-12-23T19:44:12.491Z
Learning: In src/generics/utils.js, the handleStringType function intentionally always uses OR logic when filtering string/scalar fields because a single field can only hold one value at a time (e.g., status cannot be both 'Active' AND 'Inactive'). The filterType (OR/AND) configuration only applies to array-type fields where records can contain multiple values.
📚 Learning: 2025-12-23T19:44:12.491Z
Learnt from: borkarsaish65
Repo: ELEVATE-Project/mentoring PR: 1502
File: src/generics/utils.js:0-0
Timestamp: 2025-12-23T19:44:12.491Z
Learning: In src/generics/utils.js, the handleStringType function intentionally always uses OR logic when filtering string/scalar fields because a single field can only hold one value at a time (e.g., status cannot be both 'Active' AND 'Inactive'). The filterType (OR/AND) configuration only applies to array-type fields where records can contain multiple values.
Applied to files:
src/generics/utils.js
📚 Learning: 2025-11-06T06:25:57.830Z
Learnt from: sumanvpacewisdom
Repo: ELEVATE-Project/mentoring PR: 1426
File: src/database/migrations/20251020081719-add-orgEntity-type.js:10-12
Timestamp: 2025-11-06T06:25:57.830Z
Learning: In the ELEVATE-Project/mentoring repository, entity type migrations (like 20251020081719-add-orgEntity-type.js) run before tenant-specific migrations. Therefore, down migrations for these entity types do not need to filter by organization_code and tenant_code, as multi-tenant data does not exist at the time these migrations execute.
Applied to files:
src/generics/utils.js
🔇 Additional comments (3)
src/generics/utils.js (3)
110-124: LGTM! Excellent defensive programming.The implementation is solid with proper null-safety checks and clear JSDoc documentation. The default to
@>(AND/contains-all) is a safe choice when filterType metadata is missing.
126-134: LGTM! Clean normalization helper.The function safely extracts and normalizes the filterType with appropriate use of optional chaining and sensible defaults. The JSDoc is clear and accurate.
539-612: LGTM! Proper filterType integration with clear documentation.The implementation correctly:
- Tracks filterType per entity using the
getFilterTypehelper- Documents the intentional OR-only behavior for string types (based on learnings that scalar fields can only hold one value)
- Propagates the filter operator to
handleArrayTypefor dynamic array filteringThe JSDoc on
handleStringTypeeffectively explains the design rationale.Minor typo (optional fix)
Line 561 has a minor typo:
- * The filterType (OR/AND) configuration only applies to array-type field where records can contain + * The filterType (OR/AND) configuration only applies to array-type fields where records can containBased on learnings, the string type OR-only logic is intentional and correct.
|
As discussed earlier on the call, please make the necessary changes (validation, API documentation, etc.). |
…into feature/3.3stories
…into feature/3.3stories
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@src/validators/v1/entity-type.js`:
- Around line 79-90: The current custom validator on req.checkBody('meta') calls
meta.filterType.toUpperCase() without guarding types, causing runtime TypeError
for non-object meta or non-string filterType; update the custom validator used
in both the create and update blocks to first ensure meta is an object (e.g.,
typeof meta === 'object' && meta !== null) and that meta.filterType, if present,
is a string before calling toUpperCase(); if those checks fail, throw a
validation Error (e.g., "meta must be an object" or "meta.filterType must be a
string") so invalid payloads are rejected rather than causing runtime
exceptions, and then normalize meta.filterType to uppercase and validate it
against ['OR','AND'] as before.
| req.checkBody('meta') | ||
| .optional() | ||
| .custom((meta) => { | ||
| if (meta && meta.filterType) { | ||
| const filterType = meta.filterType.toUpperCase() | ||
| if (!['OR', 'AND'].includes(filterType)) { | ||
| throw new Error('filterType inside meta must be either OR or AND') | ||
| } | ||
| meta.filterType = filterType | ||
| } | ||
| return true | ||
| }) |
There was a problem hiding this comment.
Validate meta shape and filterType type before normalization.
If meta is not an object or filterType isn’t a string, .toUpperCase() can throw and the payload isn’t cleanly rejected. Add explicit guards so invalid shapes produce a validation error instead of a runtime TypeError.
🔧 Suggested fix (apply to both create & update blocks)
req.checkBody('meta')
.optional()
.custom((meta) => {
- if (meta && meta.filterType) {
- const filterType = meta.filterType.toUpperCase()
+ if (meta && (typeof meta !== 'object' || Array.isArray(meta))) {
+ throw new Error('meta must be an object')
+ }
+ if (meta && meta.filterType !== undefined) {
+ if (typeof meta.filterType !== 'string') {
+ throw new Error('filterType inside meta must be a string')
+ }
+ const filterType = meta.filterType.trim().toUpperCase()
if (!['OR', 'AND'].includes(filterType)) {
throw new Error('filterType inside meta must be either OR or AND')
}
meta.filterType = filterType
}
return true
})As per coding guidelines, validate all incoming data thoroughly.
Also applies to: 173-184
🤖 Prompt for AI Agents
In `@src/validators/v1/entity-type.js` around lines 79 - 90, The current custom
validator on req.checkBody('meta') calls meta.filterType.toUpperCase() without
guarding types, causing runtime TypeError for non-object meta or non-string
filterType; update the custom validator used in both the create and update
blocks to first ensure meta is an object (e.g., typeof meta === 'object' && meta
!== null) and that meta.filterType, if present, is a string before calling
toUpperCase(); if those checks fail, throw a validation Error (e.g., "meta must
be an object" or "meta.filterType must be a string") so invalid payloads are
rejected rather than causing runtime exceptions, and then normalize
meta.filterType to uppercase and validate it against ['OR','AND'] as before.
2 participants
Release Notes
Features
Bug fixes
Code quality / improvements
Validation & API
Tests & docs (recommended)
Security (critical)
Contributor Statistics