Fix for ISO string modification during function metadata binding parsing #10735
Conversation
| internal static FunctionMetadata ValidateBindings(IEnumerable<string> rawBindings, FunctionMetadata function) | ||
| { | ||
| HashSet<string> bindingNames = new HashSet<string>(StringComparer.OrdinalIgnoreCase); | ||
|
|
||
| foreach (string binding in rawBindings) | ||
| { | ||
| var functionBinding = BindingMetadata.Create(JObject.Parse(binding)); | ||
| var functionBinding = GetBindingMetadata(binding); |
There was a problem hiding this comment.
Should this new behavior be an explicit opt-in for customers? With this change, all customers and bindings will experience the performance impact of the additional serialization for any bindings that pass through this flow or method.
There was a problem hiding this comment.
I don't know if we should have an explicit opt-in for a behavior that should've already been working. I believe that the use of ISO strings is only for the CosmosDB extension, so we could only check for the trigger or only for this property.
There was a problem hiding this comment.
Note: we will benchmark the two approaches and compare the results to decide how to proceed.
There was a problem hiding this comment.
Benchmarking results here.
|
Discussed offline with @liliankasem - to incorporate suggestions we will need to refactor |
Issue describing the changes in this PR
resolves #10732 (and Azure/azure-functions-dotnet-worker#2882)
Pull request checklist
IMPORTANT: Currently, changes must be backported to the
in-procbranch to be included in Core Tools and non-Flex deployments.in-procbranch is not requiredrelease_notes.mdAdditional information
Tested locally E2E the following scenarios:
StartFromTimeset to a past time started triggering and processing existing records immediately after startup (older records than start time untouched)StartFromTimeset to a future date and will process any new changes following startup. Discussed with original engineers - this feature was only meant to go into the past, so there was never a design set for future dates. This setting will not ignore changes until that future date (note: need to test InProc to see if behavior is the same there).