However, this behavior may also match user expectations in some cases, intentionally or accidentally, and this is why we consider this a breaking change.
Impact
The number of potentially affected customers is unknown, and it is not clear how we could possibly measure this. See Detection below for more details.
Compat-mode support
Introducing a feature flag to enable the old behavior is feasible but may be cumbersome.
Alternatives
The alternative is to keep the old behavior, which will continue creating confusion.
We do not have any proposal on how to fix this and avoid a breaking change at the same time.
Detection
We can introduce logs when the output data handling code hits the old or the new path (which may significantly increase log verbosity). However, it is not clear how we could automatically detect whether this is a problem or not. Neither the old nor the new behavior cause error messages, they just cause the output data to look different. There is no way for us to automatically detect whether the old format or the new format are desired, this entirely depends on how this data is consumed.
Support
The incidents-per-day impact is hard to predict. We can expect that some users learned to tolerate the old behavior, and they will have to discover and adjust to the new behavior. On the other hand, the confusing behavior will be removed, so the net expected impact is IPD reduction.
Node.js Functions SMEs will be the support contact.
Support needs to be notified of this change.
Documentation
This should be documented in the list of breaking changes for Functions v4.
Fix output data serialization format in Node.js functions:
Potentially related:
null
andundefined
values ofresult
andresult.return
in invocationRequest by davidmrdavid · Pull Request #364 · Azure/azure-functions-nodejs-worker (github.com)Motivation
The structure of the output data is currently different depending on the value, which makes certain code lead to surprising and confusing results, and makes users invent ugly workarounds: for details, see Binding Data for integers is inconsistent. · Issue #377 · Azure/azure-functions-nodejs-worker (github.com)).
However, this behavior may also match user expectations in some cases, intentionally or accidentally, and this is why we consider this a breaking change.
Impact
The number of potentially affected customers is unknown, and it is not clear how we could possibly measure this. See Detection below for more details.
Compat-mode support
Introducing a feature flag to enable the old behavior is feasible but may be cumbersome.
Alternatives
The alternative is to keep the old behavior, which will continue creating confusion.
We do not have any proposal on how to fix this and avoid a breaking change at the same time.
Detection
We can introduce logs when the output data handling code hits the old or the new path (which may significantly increase log verbosity). However, it is not clear how we could automatically detect whether this is a problem or not. Neither the old nor the new behavior cause error messages, they just cause the output data to look different. There is no way for us to automatically detect whether the old format or the new format are desired, this entirely depends on how this data is consumed.
Support
The incidents-per-day impact is hard to predict. We can expect that some users learned to tolerate the old behavior, and they will have to discover and adjust to the new behavior. On the other hand, the confusing behavior will be removed, so the net expected impact is IPD reduction.
Node.js Functions SMEs will be the support contact.
Support needs to be notified of this change.
Documentation
This should be documented in the list of breaking changes for Functions v4.
Components impacted
Node.js language worker.
Performance
No noticeable performance impact expected.