Supervisor changes encoding of emojis (UTF8 character) so that emoji is not rendered properly after consuming logs from api

[jellyfish-bot]

[fisehara] - User reports failing emoji 🚀 rendering when balena service logs emojis to the containers logs

• I debugged the issue on hostOS level, conatiner OS (ubuntu) level and balena-API calls RESTful POST JSON and streaming
  My findings are:
• That the encoding on hostOS and container level ware working fine, even journalctl on hostOS can digest or leave as is the emoji 🚀 and render it on the webTerminal
• Sending the emoji to the device/v2/:uuid/logs endpoint results in a properly rendered emoji in the weblogs view
• Sending the emoji with the https://github.com/balena-os/log-streamer tool containing an emoji results in properly rendered weblogs view.

curl -H "Authorization: Bearer <deviceKey>" https://api.balena-cloud.com/device/v2/<deviceUuid>/logs --json '[{"timestamp":1684488299969,"serviceId":2146730,"message":"sent to: 🚀\r"}]'

Using the log-streamer for testing the stream endpoint also succeeds.

I locally built the log-streamer docker container containing the rocket emoji into the test masses and run it locally

➜  log-streamer git:(main) ✗ $ docker run --rm -ti -e UUID=<deviceUUID> -e API_KEY=<deviceAPIKey> -e SERVICE_ID=2146730 docker.io/library/log-streamer 
Fri, 19 May 2023 10:38:25 GMT - Test message No. 0 🚀. Next message in 1(s)

I conclude that in some way the supervisor (14.9.2)is changing / not properly digesting the log message from the hostOS journalctl stream and sends the data already tainted to the balenaAPI log endpoints.

[jellyfish-bot]

[fisehara] This has attached https://jel.ly.fish/56766023-6c22-4c3b-9369-69be5ff7b9ad