Hey, great question, it’s already the way you expect it, we just need to communicate it better in the UI!
When the device boots up, two containers are initiated side by side: your application’s container, and the supervisor that manages the device & communicates with resin.io including your logs. The supervisor needs some time, and we are not holding back your application’s start depending on the supervisor.
The outcome is that there’s an about 30s window, when the application is running (freshly started!), but there are no logs for it on the start, as the supervisor is still catching up. The application already running is to provide feedback to you, that it actually started, otherwise you might wonder (even more), whether it does run (especially if your application does not show much logs).
You could for example test this by deploying this simple Dockerfile:
FROM resin/raspberrypi3-debian
# Echo seconds since container start to the log
CMD i=0; while : ; do echo $i; sleep 1; i=$((i+1)); done
Since the count is low value, it shows the container is started anew on reboot, eg ~17s ago in this test:
We definitely need to document this more, and some of the architecture decisions and behaviour is likely to change in the future to surprise people less (like it did surprise you), but your application should always start from fresh!