Celery healthcheck fails in `set -e; cmd1;cmd2` and functions in `set -e; cmd1 && cmd2`

Problem

docker compose fails app container for django celery app only in one of the 4 potential use cases. In each of the cases, the script in question is running inside the same django python docker image.

The HOST OS for the docker env change but not the container. So, for all these test we are using the identical version of bash for this script which is the docker container entry-point

Host OS macos: set -e; cmd1;cmd2 or set -e; cmd1 && cmd2 work identically
Host OS ubuntu: set -e; cmd1;cmd2 fails, set -e; cmd1 && cmd2 works

Container Info:

OS: Debian GNU/Linux 12 (bookworm)
bash: 5.2.15(1)-release (aarch64-unknown-linux-gnu)

In the failure case we see that django call to celery health check times out.

I don't understand how set -e and && result in different behaviors given the following entry-point scripts

Failing ubuntu case

set -e
...
python my_django_app.py start celery-worker celery-beats celery-healthcheck-worker
daphne -b 0.0.0.0 -p 8000 my_django_app.asgi:application

Passing all cases

set -e
...
python my_django_app.py start celery-worker celery-beats celery-healthcheck-worker && daphne -b 0.0.0.0 -p 8000 my_django_app.asgi:application

Puzzle

In my understanding , the set -e with cmd1; cmd2 and set -e with cmd1 && cmd2 should result in the identical behavior but it doesn't seem to. The fact that the error is around a call celery -A my_django_app status make me suspect the relationship of django, celery to daphne and suggests some kind of race condition but this seems like it should not be so

Again, given that set -e is set, 1st failure terminates the entry point. There's a relationship change introduced by && but I don't think there should be.

What am I missing?