Verify server receipt delivery through configurable UI tunnel
Test and deploy MQTT backend / test (push) Successful in 1m46s
Test and deploy MQTT backend / deploy (push) Successful in 13s

This commit is contained in:
2026-10-10 08:41:31 +03:30
parent 9a32f634d4
commit 55f11c9956
3 changed files with 145 additions and 5 deletions
+12
View File
@@ -43,3 +43,15 @@ docker compose --env-file .env -f compose.yaml up -d --force-recreate backend
```
During deployments do not run a simultaneous manual rollback. Before changing broker credentials, update the server's private `secrets/backend.json` (root:10001, mode 0640, parent directory 0750) and restart backend. Do not rotate the broker's existing credentials as part of ordinary backend deployments.
## Deployment verification — 2026-10-10
The deployed observer was healthy and MQTT-ready. Independent device clients passed MQTT3.1.1 and5 over both plaintext and TLS, receiving receipt ACKs for raw text, arbitrary JSON and empty messages. Exact incoming/outgoing evidence was verified in the SERVER UI through the private SSH tunnel. Native response/correlation, controlled wire DUP and auth/TLS rejection checks passed. Duplicate local observer remained stopped. This is independent test-client evidence, not physical ESP32 firmware proof.
For repeatable checks against a tunnel, use:
```sh
rtk python3 scripts/check_receipts.py --credentials esp32-test-kit/connection.txt --ca esp32-test-kit/ca.crt --viewer-url http://127.0.0.1:18081
```
The script allows bounded waiting for UI evidence (default15 seconds), reports transient HTTP failures and still fails if matching evidence never appears. The old tunnel timeout was not reproduced; no historical root cause is claimed. Broker restart/persistence verification remains a separate Sprint5 gate.