-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Major bug in HttpTrigger receival of payload #607
Major bug in HttpTrigger receival of payload #607
Comments
@surgupta-msft feel free to email me directly in case you want to see this in action. Thank you. |
@verschaevesiebe Thank you for bringing up the issue. I was able to reproduce it. Repro Steps -
{
"name": "Azure",
"payload": {
"dossier_id": "TEST_DOS",
"test": {
"abc" : "2",
"bytes" : 2
}
}
} It seems to be happening with Node apps. I tried repro with powershell and dotnet apps but did not see this issue. cc @AnatoliB Repro app: surg-node-test6 Pasting stack trace below -
|
Hi @verschaevesiebe I can also reproduce the bug and your analysis appears to be correct. It's only an issue with fields specifically named "bytes" and it's because we try to parse that field into a Buffer (which fails when your field is a number). We will get this fixed - but in the meantime unfortunately the only workaround I'm aware of is to rename your "bytes" field to something else. |
Hi @ejizba, Thanks, that's indeed my workaround for now. Naming it "bytess" 😄 The unfortunate part is that we're receiving these events from external sources so we're applying a translation now through a logic app before being able to forward it to any function, because they all crash and restart 😢 Thanks for the triage and investigation 👍🏽 |
I made some changes a little bit ago to prevent random errors from crashing the whole app. This was included in host version 4.7.2 which just finished rolling out in Azure this month. Core tools has not shipped with the changes yet, but that should happen in the next week or two. This means the specific invocation may fail in Azure, but you should no longer see it crash the app as a whole.
We will likely merge the fix in August, but it can take a month or two to rollout, so September in an ideal scenario? As an aside, the delay for bug fixes like this is a known pain point and we're working to improve it. Specifically, we're moving a lot of our logic into an npm package instead of shipping it all in Azure. In that scenario, we could fix the bug and ship a new npm package within weeks of discovering the bug and all you'd have to do is update your package reference. Tracked by #568 which I expect to rollout in the September/October timeframe as well. |
Main points: - We don't want `toCamelCase` to call `fromRpcTypedData` because it traverses an entire object recursively and only the top level objects should be RpcTypedData - We will remove triggerMetadata from http/timer triggers. That information is best found on the request/timer objects instead Related to all of these bugs: Azure/azure-functions-nodejs-worker#607 Azure/azure-functions-nodejs-worker#274 Azure/azure-functions-nodejs-worker#204 Azure/azure-functions-nodejs-worker#388
Hi @verschaevesiebe sorry this took way longer than I was originally hoping, the fix finally finished rolling out in Azure as a part of host v4.14.0. Thanks for reporting! |
Hi All,
After some investigation I'm having trouble with Azure functions.
This is a simple Azure function which receives a HTTP Trigger call with an application/json Content-Type.
The function works perfectly fine for all invocation as always.
However, we have added an additional field to our JSON payload which is "bytes": 1253.
To give some small context, the bytes field is just the length of a file we have passed to another system. So everything in this event is text or integer. When passing this to the function
When the addition "bytes" field is added to the payload, the function invocation/function app crashes and throws the following error.
Do mind the Received type number (2). Referring to the bytes field (also number 2) in the example below.
If we change the value of the bytes field to a string like so "bytes": "test" then the invocation does not crash and doesn't throw an error.
I believe that something in the function source code checks for a "bytes" text and tries to parse it ?
The issue only occurs when the "bytes" field is at least 3 levels deep into the JSON object.
It's unbelievable and frustrating to have to be looking for this bug 🗡️ .
Hope someone can investigate and possibly resolve it.
PS: We're using typescript and it is being decompiled into JavaScript.
The function packages i've been using to test this replication are
[email protected]
@azure/functions": "^1.2.3
@azure/functions": "^3.2.0
Above is the response from the function that I've found somewhere on Azure so unsure if it's the correct request-context id for someone to take a look.
The text was updated successfully, but these errors were encountered: