This change creates a big problem (at least for dart cloud functions): https://github.com/appwrite/appwrite/pull/6317
Change is here: https://github.com/open-runtimes/open-runtimes/blob/2a069cf9bec98e18a096633b5848cde12b4fe319/runtime
By assuming that the body HAS to be json parseable, all cloud functions will throw an error if the request is not json.
So everyone who has existing functions that accept string request bodies or anything not json parsable (or anyone who wants to in the future) can no longer do that.
All changes to make this work going forward require not only backend refactors, but frontend changes too.
It would be really nice if cloud functions stop assuming things like this. The recent big change helped reduce these assumptions by a lot, but this is still an issue.
Opened an issue: https://github.com/appwrite/appwrite/issues/6462
this only applies to functions triggered by event...which in those cases, the body should always be JSON
aahh -- make sense
I thought I was getting this error though not in that situation. I'll triple check and report back.
are you getting a parse error from a user event?
It's not through an error. Thanks for the help. context.req.body is giving me a string, so I'm not sure what to expect. Will body be parsed / not parsed depending on what triggered the execution?
Body will only be parsed as JSON if the content type header is application/json
ahh gotcha -- that makes more sense.
[SOLVED] v1.4.4 Functions Body Parsed / Not Parsed
Recommended threads
- After a GET request is passed to functio...
Create execution in the console can normally retrieve the get parameters。WHy?
- function subdomain ssl certs
The generated subdomain isn't getting a valid ssl cert, I was wondering if appwrite automatically generates one or uses a wildcard for *.functions.domain.com? ...
- Python Function Deployment hits General ...
The same deployment was working without issue yesterday and I have not hit any free tier limits yet. How do I figure out what's happening? Are you having issues...