-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Query Execution
-
ALL
Referencing per-statement c values in the q field for an update works on mongod but does not work on mongos when the collection is sharded. E.g.
db.runCommand({ update: 'coll', updates: [{ q: {$expr: {$eq: ["$skey", "$$targetKey"]}}, u: [{'$set': {skey: '$$replacedKey'}}], c: {targetKey: 'MongoDB', replacedKey: 'MongoDB2'} }] });
Gives a response with a write error:
{ "index" : 0, "code" : 17276, "errmsg" : "Could not parse update query { $expr: { $eq: [ \"$skey\", \"$$targetKey\" ] } } :: caused by :: Use of undefined variable: targetKey" }
Additionally, the bulkWrite command being added in PM-1452 inherits the limitation for its per-statement constants as bulkWrite shares the same targeting logic for updates. If/when this is fixed, we should ensure the fix also works for updates in the bulkWrite command.
The issue is that we fail to canonicalize the update's query field here because the parsing logic does not have access to the constants. A fix might involve updating the logic so that the constants are passed via the ExpressionContext there, similar to what is done for the command-level let values.