In SBE, for almost all aggregate operators, all of the operator's arguments are evaluated first before doing typechecking or anything else. This was an intentional design decision.

From what I can tell, the only aggregate operators that intentionally have "short-circuit" style behavior are as follows:

• $and - Short-circuits evaluation of the remaining arguments when an argument evaluates to false (or something that when coerced to boolean will produce "false")
• $or - Short-circuits evaluation of the remaining arguments when an argument evaluates to true (or something that when coerced to boolean will produce "true")
• $switch - Short-circuits evaluation of the remaining case/then's when a case evaluates to true (or something that when coerced to boolean will produce "true")
• $ifNull - Short-circuits evaluation of the remaining arguments when an argument evaluates to a value that is not null/missing

Aside from the operators listed above, unless there is a specific reason, each aggregate operator's arguments should be evaluated first before doing anything else.

I noticed that the SBE implementation of $concatArrays seems to exhibit "short-circuit on null" behavior. Here is an example that demonstrates this:

> db.adminCommand({setParameter: 1, internalQueryEnableSlotBasedExecutionEngine: true});
{ "was" : false, "ok" : 1 }

> db.c.find()
{_id: 1, a: null, b: "foo"}

> db.c.aggregate([{$project: {x: {$concatArrays: [[1,2], "$a", {$add: [1,"$b"]}]}}}])
{_id: 1, x: null}

The goal of this task is to determine if $concatArrays in SBE should evaluate all of its arguments first before doing typechecking or anything else, and if so, to update the SBE implementation of $concatArrays accordingly.