[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
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.
[fisehara] - User reports failing emoji 🚀 rendering when balena service logs emojis to the containers logs
My findings are:
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
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.