backend: evaluate container-native MQTT recovery
I maintainer di solito rispondono entro 1 giorno
@Aibolit66 ci sta già lavorando.
Dal 23/8/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Context
The MQTT listener can remain alive while its loop is wedged. The current solution detects this through a heartbeat healthcheck and uses a willfarrell/autoheal sidecar with Docker socket access to restart the unhealthy container.
The ServerSideUp image normally relies on S6 process supervision and container restart policies. However, its built-in checks do not cover the custom mqtt:listen command or detect a process that is alive but wedged.
Scope
- Evaluate whether recovery should be aligned with the ServerSideUp/S6 model.
- Preserve detection and recovery of a running but wedged MQTT listener.
- Consider terminating the container from the healthcheck or using an S6-managed watchdog.
- Compare the complexity, reliability, and security implications with retaining the current autoheal solution.
- If container-native recovery is worthwhile, remove autoheal and supersede ADR-0028.
- If it is not worthwhile, keep autoheal, pin the image version, and document why this is the simpler solution.
Discussion / decision needed
Does implementing container-native recovery provide enough benefit to justify the additional complexity, or is retaining and version-pinning autoheal the simpler and more reliable option for this Docker Compose deployment?
Related: #52 and docs/adr/0028-mqtt-listener-liveness-healthcheck.md.
- Lingua principale
- PHP
- Stelle
- 26
- Fork
- 2
- Merge medio
- 2g 19h
- PR unite (30g)
- 10
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Open-Locker/Open-Locker
-
mobile-app: remove the "Schließen" button from the compartment sheetForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertamobile-app
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
Open-Locker/Open-Locker#352 ·
I maintainer di solito rispondono entro 1 giorno
-
docs
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
Open-Locker/Open-Locker#287 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement mobile-app
Difficoltà 4/5 Più di una settimana Idoneità per principianti 15/100
Open-Locker/Open-Locker#351 ·
I maintainer di solito rispondono entro 1 giorno
-
backend bug iot client
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
Open-Locker/Open-Locker#350 ·
I maintainer di solito rispondono entro 1 giorno
-
backend iot client
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
Open-Locker/Open-Locker#345 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Open-Locker/Open-Locker
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
0. Needs triage 35-feedback bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
getgrav/grav-plugin-api#74 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
heroku/heroku-buildpack-php#1024 ·
I maintainer di solito rispondono entro 1 giorno