fix(mqtt): clear the stale SNTP status before starting the new request

The reset was on the wrong side of configTime(). configTime() configures the
server, calls sntp_init(), and returns — the new request is live before it comes
back — so a fast reply could set SNTP_SYNC_STATUS_COMPLETED inside that call, and
the reset immediately after would erase it. The following ten seconds of polling
would then see nothing and reject a server that had in fact answered. On the
`set mqtt.ntp` path that surfaces as a good server failing validation.

Stop any running session first, discard its status, then start the new one, so
the only completion observable is the one being waited for.
This commit is contained in:
agessaman
2026-08-14 19:58:39 -07:00
parent 1a01344e71
commit ee2f866b10
+8 -2
View File
@@ -3986,15 +3986,21 @@ bool MQTTBridge::syncTimeWithNTP(bool force, bool primary_only) {
for (int s = 0; s < server_count && !ntp_ok; s++) {
const char* server = servers[s];
MQTT_DEBUG_PRINTLN("SNTP fallback trying %s...", server);
configTime(0, 0, server);
// A plausible clock is not evidence this server answered. The device usually
// already holds valid time here — from an earlier sync, or the RTC — so polling
// time(nullptr) declared the very first server successful without a packet ever
// arriving, stopped the fallback walk there, and refreshed _last_ntp_sync. Worse
// on the `set mqtt.ntp` validation path, where a typo is supposed to fail fast.
// Wait for SNTP itself to report completion. The status is one-shot — reading
// COMPLETED clears it — so drop any result an earlier sync left behind.
// COMPLETED clears it — so drop any result an earlier sync left behind, and do
// that *before* starting this one: configTime() returns after sntp_init(), so a
// fast reply can complete inside it, and clearing afterwards would erase the
// very result being waited for.
if (sntp_enabled()) {
sntp_stop();
}
sntp_set_sync_status(SNTP_SYNC_STATUS_RESET);
configTime(0, 0, server);
for (int i = 0; i < 20; i++) {
delay(500);
if (sntp_get_sync_status() != SNTP_SYNC_STATUS_COMPLETED) continue;