Mike Stall

ICollector & IAsyncCollector should behave identically here w.r.t. flushing semantics. If they're not, that's going to be very confusing and we should fix it.

Consider a help on LambdaFormulaValue like: ``` public async ValueTask EvalInRowScopeAsync(RecordValue rowScope) { SymbolContext childContext = _context.SymbolContext.WithScopeValues(rowScope); var newScope = _context.NewScope(childContext); var result = await this.EvalInRowScopeAsync(newScope).ConfigureAwait(false); return result; } ```

+1. There's a related issue of how we pass the type into the function at runtime. Ideally, this would also be a dtype (and not a string to deserialize).

The challenge here is an ambiguity between scalar and tabular overloads. `Sum(U1, U2)` // scalar or tabular? `Sum(1,2) // scalar` `Sum([10,20,30], Value) // tabular`

The problem is that fundamentally, `a && b && c` shouldn't threaten a stack overflow.

This is doable, but will require a breaking change to update TexlNode. The current node is a binary op with just left and right - which mandates a deep tree...

Fixing this on Fx side is a too large of breaking change. Even after the breaking change to AST, every visitor needs to be updated We have made a fix...

Can you clarify: what do incoming and outgoing messages mean here? Are you saying that an event is being processed multiple times?

We already implement this in our tests: https://github.com/Azure/azure-webjobs-sdk/blob/3696dd28df66996b1adcc0697f0d0f88f865cb64/test/Microsoft.Azure.WebJobs.Host.UnitTests/Common/BindingPathAttribute.cs This means making that public.