Plumb [File] on SDK's new BindToInput rule. #314
Conversation
FileTrigger is not changed. The key difference here is remove the file binding provider classses and using the rules. See FilesExtensionConfig.Initialize
| var fileInfo = GetFileInfo(attribute); | ||
| if ((attribute.Access == FileAccess.Read) && !fileInfo.Exists) | ||
| { | ||
| return null; |
There was a problem hiding this comment.
Letting the FileInfo.Open() call below call an exception below may provide a more clear error message than returning a null value for the Stream.
There was a problem hiding this comment.
Looking at your unit tests on the other PR, it appears we want to return null here since there isn't a reliable exception for the file not existing. Adding a comment here would help make that more clear.
There was a problem hiding this comment.
Right, null is the contract for "does not exist"
| context.Config.RegisterBindingExtensions( | ||
| new FileTriggerAttributeBindingProvider(_filesConfig, context.Trace), | ||
| new FileAttributeBindingProvider(_filesConfig, context.Config.NameResolver)); | ||
| new FileTriggerAttributeBindingProvider(_filesConfig, context.Trace) |
There was a problem hiding this comment.
Does this binding provider now handle trigger as well as non-trigger bindings (e.g. the input/output file bindings). If so, then it might make sense to remove "trigger" from its name. All the e2e tests are passing?
There was a problem hiding this comment.
No change to triggers yet. So we still need the TriggerBindingProviders. I had a separate idea that may improve this, but will tackle later.
|
Superseded by #331 |
FileTrigger is not changed.
The key difference here is remove the file binding provider classses and using the rules. See FilesExtensionConfig.Initialize
This relies on Azure/azure-webjobs-sdk#1387 from SDK.