Update runner drops secret-type variables, causes health check rollback

Posted by mrgrue

- Platform: generic, /opt/sparkbox - Running sparkbox update all rolls back every time due to sb-duplicati, sb-homarr, sb-speedtest failing health checks - DUPLICATIPASSWORD is set correctly in .env (verified with od -c — clean value, no whitespace) - docker compose --env-file /opt/sparkbox/.env -f /opt/sparkbox/modules/backup/docker-compose.yml config resolves DUPLICATIPASSWORD as blank - The backup module compose declares DUPLICATIPASSWORD with type: "secret" — this appears to be causing the update runner to drop the value during recreate - Also: "Share to demox" button not pre-populating conversation context (blank form) (Platform is UGREEN, not sure if "generic" up there is misleading)

2 replies

tomspark wrote:

Thanks for the detailed writeup — real bug, and you're on the right track. The type: secret label is just a dashboard annotation, but the mechanism underneath is real: on a recreate the dashboard can leak an empty copy of that password into the environment, and Compose gives the live environment priority over your --env-file, so ${DUPLICATIPASSWORD} resolves blank even though your .env is clean. We shipped this exact fix for the database modules on Jun 10 and we're extending it to cover password vars like Duplicati's now. What I can't explain yet is sb-homarr and sb-speedtest — those don't touch that password, so they're failing for a different reason. Could you grab sudo docker logs sb-homarr --tail 50 and the same for sb-speedtest right after a rolled-back update? That'll tell us if it's the same timing window or something separate. Thanks for flagging the share-to-demox thing too — noting that one as well.

mrgrue wrote:

I updated SB from .240 to .245, and then requested all apps be updated... and it worked! First time in a couple weeks, so that's great news! I'm not sure what changed from 240 to 245, but thank you!