You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* refactor: add TemplateVoid for condiguration type
* fix: add modifyCollection parameter validation (#3)
ModifyCollection was the only non-trivial operation with zero parameter
validation, allowing invalid values like validationLevel: "banana" to
pass through unchecked until MongoDB runtime rejection.
**Original issue:**`InsertOperator.applyInternal()` had a redundant guard `if(op.getDocuments() == null || op.getDocuments().isEmpty()) { return; }` that silently did nothing instead of failing when documents were missing.
39
39
**Resolution:** The silent guard was removed from `InsertOperator.applyInternal()`. Structural validation now runs at load time via `InsertParametersValidator` (called from `MongoOperation.validate()`), which catches null, empty, and malformed documents before any change executes. The operator no longer needs a defensive check — if documents are invalid, the framework rejects the change at load time.
40
40
41
-
### #3 - HIGH: `modifyCollection` has ZERO parameter validation
42
-
**File:**`MongoOperationValidator.java:239-240`
43
-
**Impact:** The `validateByType()` switch falls through to `default: return new ArrayList<>()` for `MODIFY_COLLECTION`, `DROP_COLLECTION`, `DROP_VIEW`, and `CREATE_COLLECTION`. While the last three genuinely need only a collection name, `modifyCollection` accepts `validator`, `validationLevel`, and `validationAction` parameters. None are validated. A user could pass `validationLevel: "banana"` and it would pass validation, only to fail at MongoDB runtime.
44
-
**Risk:** Silent misconfiguration of collection-level validation rules in production.
45
-
**Fix:** Add `case MODIFY_COLLECTION: return validateModifyCollection(op, entityId);` with checks for valid `validationLevel` values (`off`, `strict`, `moderate`) and valid `validationAction` values (`error`, `warn`).
41
+
### #3 - ~~HIGH: `modifyCollection` has ZERO parameter validation~~ RESOLVED
42
+
**Status:** Fixed by adding `ModifyCollectionParametersValidator`.
43
+
**Original issue:**`modifyCollection` used `OperationValidator.NO_OP` in `MongoOperationType`, so none of its three parameters (`validator`, `validationLevel`, `validationAction`) were validated. A user could pass `validationLevel: "banana"` and it would pass validation, only to fail at MongoDB runtime.
44
+
**Resolution:**`ModifyCollectionParametersValidator` now validates at load time: requires at least one recognized parameter, checks `validator` is a document (Map), checks `validationLevel` is one of `off`/`strict`/`moderate`, and checks `validationAction` is one of `error`/`warn`. Multiple errors accumulate. Wired into `MongoOperationType.MODIFY_COLLECTION` replacing the `NO_OP` validator.
46
45
47
46
### #4 - HIGH: Type-unsafe parameter extraction throughout MongoOperation
48
47
**File:**`MongoOperation.java:46-115`
@@ -103,7 +102,7 @@ While the validator catches some of these cases, the validator runs only on the
0 commit comments