Investigate live objects for trigger objects and input bindings

[joeyaiello]

Today, the only trigger type or input binding that gets a live object (as opposed to a dead object with a bag of static properties) is the Http trigger.

For additional triggers, it may be more useful for live objects to come in via the trigger. E.g. users may want "re-hydrated" live objects via the blob binding, so that they can take those objects and use them in scenarios with Azure PowerShell.

First step here should be to investigate where we put our rehydration logic (is it in the gRPC layer?). Then, we can decide whether this is actually something that users care about, and prioritize a list of bindings/triggers according to customer input.

We should decide which bindings we want to support for live objects within the Preview milestone.

[JustinGrote]

Posting here rather than a new issue as it is likely related: The timertrigger returns the Schedule and IsPastDue properties, but trying to call the ScheduleStatus property returns

[6/4/2019 4:00:50 AM] ERROR: Cannot bind argument to parameter 'InputObject' because it is null.
[6/4/2019 4:00:50 AM] Result: ERROR: Cannot bind argument to parameter 'InputObject' because it is null.
Exception: Cannot bind argument to parameter 'InputObject' because it is null.
Stack:    at System.Management.Automation.CmdletParameterBinderController.BindValueFromPipeline(PSObject inputToOperateOn, MergedCompiledCommandParameter parameter, ParameterBindingFlags flags)
[6/4/2019 4:00:50 AM]    at System.Management.Automation.CmdletParameterBinderController.BindUnboundParametersForBindingStateInParameterSet(PSObject inputToOperateOn, CurrentlyBinding currentlyBinding, UInt32 validParameterSets)
[6/4/2019 4:00:50 AM]    at System.Management.Automation.CmdletParameterBinderController.BindUnboundParametersForBindingState(PSObject inputToOperateOn, CurrentlyBinding currentlyBinding, UInt32 validParameterSets)
[6/4/2019 4:00:50 AM]    at System.Management.Automation.CmdletParameterBinderController.BindPipelineParametersPrivate(PSObject inputToOperateOn)
[6/4/2019 4:00:50 AM]    at System.Management.Automation.CmdletParameterBinderController.BindPipelineParameters(PSObject inputToOperateOn)
[6/4/2019 4:00:50 AM]    at System.Management.Automation.CommandProcessor.Read().

Use Case: Measuring from when the function was scheduled to when it reached the environment, for benchmarking/monitoring cold/warm start times.

EDIT: Was able to workaround this with triggerdata from UTCNow

[JustinGrote]

Additional Use Case: I have a function with a queue trigger that I want to "fail", but I don't want it to retry in the queue 5 more times (or whatever), say because the exception is a known configuration exception and not a transient exception such as the server temporarily offline. Currently I have no way to get at the queue object and dequeue it before throwing the error, and as soon as I throw the error, Azure Functions will retry the queue object.

EDIT: Crappy temporary workaround, requires the function to run twice and slightly pollutes the telemetry, but it's better than repeating the error X times.

try {
    throw "Configuration Error"
} catch {
    if ($TriggerMetadata.dequeuecount -gt 1) {
        Write-Output "Skipping Retry of Queue Item $($TriggerMetadata.id)"
        exit 0
    } else {
        throw $PSItem
    }
}

[TylerLeonhardt]

Do we get any sort of information as to what Queue the queue item data came from? Without that, this issue would need some help from the Azure Functions Host.