faas: Research item: User-defined error codes in watchdog
Expected Behaviour
Return 200/404/400 etc from your function code.
Current Behaviour
200 / 400 / 500 are supported but used internally to the watchdog only
Calling os.exit with a non-zero code may also cause a 500 to be returned.
Possible Solutions
- Allow user to set environment such as
Http_Status_Codeand let the watchdog read this before returning. (Appears this doesn’t work) - Read the “exit code” instead (note - this only goes between 0-255)
- Marshal a custom format for responses (adds work / non-standard)
Workaround
Return 200 with a well-formed body - let that indicate whether it was successful.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 3
- Comments: 18 (10 by maintainers)
To be clear, FD 0, 1, and 2 are mapped to: STDIN, STDOUT, STDERR.
I’ve been using FD 3 as an additional communication channel for sending JSON between the parent and child process. Not sure if it’s best practice, but it has been working and allowing for expressive APIs inside functions.
I don’t see any specific reason why you couldn’t just write the status header out directly to STDOUT and parse that output, but in our case we ended up not wanting to send anything but the response body itself over STDOUT.