fix(network): persist WiFi config before applying it (closes #352) by tylerkron · Pull Request #391 · daqifi/daqifi-core

tylerkron · 2026-07-24T21:06:55Z

Summary

Alternative to #376, which fixes #352 by gating network reconfiguration to USB. This fixes it by reordering two commands, keeping WiFi reconfiguration working.

The field case that motivated this: switching a DAQiFi from one hotspot to another out in the field, with no USB cable to hand.

The premise #376 rests on doesn't hold

#376 treats the dropped control connection as the defect. But if you move a device onto a different network, the connection carrying your commands must die — that is the operation succeeding, not a race to be avoided. #376 makes that impossible-to-avoid outcome unreachable by forbidding the workflow.

The real defect is narrower: Core saves last, so the save is what gets lost.

before: SET… -> APPLY -> delay -> SD off -> LAN on -> SAVE   # SAVE stranded behind the restart
after:  SET… -> SD off -> LAN on -> SAVE -> APPLY -> delay   # durable before anything restarts

Why persist-first is valid (firmware-verified)

#352 and #376 both flagged persist-first as depending on unverified firmware semantics. It's now verified, in the firmware source and on hardware:

LAN:SAVE persists the staged settings, not the active ones. SCPI_LANSettingsSave memcpy's BOARDRUNTIME_WIFI_SETTINGS straight to NVM with no dependency on APPLY having run.
LAN:ENAbled writes isEnabled into that same struct and restarts nothing, so it moves ahead of the save (to be persisted) and ahead of the apply (the firmware only fires a REINIT when isEnabled is set).
The restart is asynchronous and the save is link-independent — APPLY enqueues a REINIT event, and SaveToNvm is a local flash write. Once the command reaches the device, persistence completes on-device regardless of the connection.
Bare APPLY never writes NVM, so applying after saving cannot clobber what was saved.

Bench validation

On an Nq1 (WINC1500 fw 19.7.7), over USB:

Test	Result
Stage SSID + `SAVE`, no `APPLY` at all, cold boot	Persisted
Full new sequence with a successful `APPLY` (every command `0,"No error"`), reboot	Persisted through a real module REINIT + power cycle
Device restored to original configuration afterwards	Verified field-by-field

One note for anyone reproducing: APPLY returns -200 when the device is in standby (SYSTem:POWer:STATe? -> 0) because the radio isn't initialized. Power up first. That is unrelated to this change — but it does reinforce the ordering, since APPLY is the step that can fail and it no longer has the save riding behind it.

Behavior change

Reconfiguration over WiFi/TCP now works instead of being rejected. Over WiFi the control connection is expected to drop when the target network changes; the config is already in NVM, so the device returns on the new network with settings intact. Documented on both INetworkConfigurable and the implementation so callers reconnect rather than treat the drop as an error. Over USB the observable sequence is unchanged apart from the ordering.

Tests

Three ordering regressions — save-before-apply over USB, the same over a WiFi transport, and apply-is-the-final-command (guards against a future trailing command being appended into the restart window). All three fail against the old ordering, with the diagnostic showing SAVE at index 7 behind APPLY at index 4.

_OverWifi_StillReEnablesLan from #347 is kept and still passes — #376 had to delete it.

Full suite 1838 passed / 2 skipped on net9.0 + net10.0; 0-warning Release on both TFMs.

Note

Opened for review, not merging. If this approach is preferred, #376 should be closed as superseded — the two are mutually exclusive.

🤖 Generated with Claude Code

UpdateNetworkConfigurationAsync sent LAN:APPLY before LAN:SAVE. APPLY restarts the WiFi module, so the trailing SAVE could be lost to that restart, leaving the device applied-but-not-persisted: the new config live now, gone on the next power cycle. Reorder to persist-first — stage, enable LAN, SAVE, then APPLY last: before: SET… -> APPLY -> delay -> SD off -> LAN on -> SAVE after: SET… -> SD off -> LAN on -> SAVE -> APPLY -> delay The firmware persists the *staged* runtime settings, not just the live ones (SCPI_LANSettingsSave memcpy's BOARDRUNTIME_WIFI_SETTINGS to NVM), so saving first is valid. LAN:ENAbled writes isEnabled into that same struct and restarts nothing, so it moves ahead of the save to be persisted — and ahead of the apply, since the firmware only fires a module REINIT when isEnabled is set. APPLY is now last, so no command can be lost to the restart. This keeps reconfiguration working over WiFi/TCP rather than gating it to USB. The connection still drops when switching networks — that is inherent to leaving the network carrying the control link, not a fault — but the config is already in NVM by then, so the device comes back on the new network with the settings intact. Documented as the expected contract so callers reconnect rather than treat the drop as an error. Bench-validated on an Nq1 (WINC1500 fw 19.7.7): - staged SSID + SAVE, no APPLY at all -> survived a cold boot - full new sequence with a successful APPLY (all commands 0,"No error") -> survived a real module REINIT plus a power cycle - APPLY does not write NVM, so applying after saving cannot clobber it - device restored to its original configuration afterwards Tests: 3 ordering regressions (save-before-apply over USB and WiFi, and apply-is-final). All three fail against the old ordering. Full suite 1838 passed / 2 skipped on net9.0 + net10.0, 0-warning Release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

qodo-code-review · 2026-07-24T21:08:11Z

PR Summary by Qodo

Persist WiFi config before LAN:APPLY to survive module restart (#352)

🐞 Bug fix 🧪 Tests 📝 Documentation 🕐 40+ Minutes

AI Description

• Reorder WiFi reconfiguration to persist staged settings before triggering WiFi module restart.
• Define WiFi/TCP behavior contract: apply may drop the control connection; callers must reconnect.
• Add regression tests to enforce SAVE-before-APPLY and no commands after APPLY.

Diagram

graph TD
  A["Caller"] --> B["UpdateNetworkConfigurationAsync"] --> C["Stage WiFi/LAN settings"] --> D["LAN:ENAbled + SD off"] --> E["LAN:SAVE (persist)"] --> F["LAN:APPLY (restart)"] --> G["WiFi module restarts"]
  E --> H[("NVM")]
  G --> I["WiFi/TCP link drops"]

High-Level Assessment

The following are alternative approaches to this PR:

1. Gate reconfiguration to USB-only

➕ Avoids losing the control channel mid-sequence over WiFi/TCP
➕ Simpler runtime expectations for clients
➖ Prevents an important field workflow (switch hotspots without USB)
➖ Treats an expected link drop as an error rather than part of the operation

2. Expose explicit two-phase API (SaveAsync / ApplyAsync)

➕ Makes the durability vs. activation boundary explicit for callers
➕ Callers can choose to defer APPLY until ready to disconnect
➖ More public surface area and more client complexity
➖ Still requires correct ordering guidance and tests

3. Add a device-side atomic command (persist+apply)

➕ Eliminates host-side ordering concerns
➕ Could guarantee transactional behavior across restart
➖ Requires firmware changes and coordination
➖ Harder to deploy quickly compared to host-side fix

Recommendation: Keep the PR’s persist-first ordering: it preserves the WiFi/TCP field workflow while making durability independent of the APPLY-triggered restart. Consider a two-phase API only if future callers need finer control over when the disconnect occurs; otherwise the current contract + regression tests are the simplest robust fix.

Files changed (3) +137 / -16

Bug fix (1) +38 / -13

DaqifiStreamingDevice.csReorder network reconfiguration to persist settings before applying (WiFi restart) +38/-13

Reorder network reconfiguration to persist settings before applying (WiFi restart)
• Updates UpdateNetworkConfigurationAsync to stage settings, disable SD / enable LAN, save to NVM, then apply last, followed by a restart delay. Adds remarks documenting that WiFi/TCP control connections are expected to drop during APPLY and that callers should reconnect on the new network.
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs

Tests (1) +82 / -0

NetworkConfigurableTests.csAdd regression tests enforcing SAVE-before-APPLY and APPLY-last ordering +82/-0

Add regression tests enforcing SAVE-before-APPLY and APPLY-last ordering
• Adds three tests that assert LAN:SAVE is sent before LAN:APPLY (including over WiFi/TCP) and that no commands are sent after APPLY. These tests prevent regressions where the APPLY-triggered WiFi restart could strand later commands and lose persistence.
src/Daqifi.Core.Tests/Device/Network/NetworkConfigurableTests.cs

Documentation (1) +17 / -3

INetworkConfigurable.csDocument persist-first/apply-last contract and expected WiFi/TCP disconnect +17/-3

Document persist-first/apply-last contract and expected WiFi/TCP disconnect
• Updates interface documentation to reflect the new command sequence: enable LAN, save first, then apply (restart) and wait. Explicitly documents that WiFi/TCP reconfiguration may drop the connection and clients should reconnect.
src/Daqifi.Core/Device/Network/INetworkConfigurable.cs

qodo-code-review · 2026-07-24T21:13:01Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Canceled despite persisted change~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

UpdateNetworkConfigurationAsync can throw OperationCanceledException during the post-apply
Task.Delay even though it already sent LAN:SAVE and LAN:APPLY, so the device may have durably
changed networks. When that happens, the method also skips updating the in-memory
_networkConfiguration fields, leaving callers with a "canceled" result and stale local state.

Code

src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[R1322-1338]

            Send(ScpiMessageProducer.SaveNetworkLan);

+            // Apply last: this restarts the WiFi module. Over a WiFi/TCP control connection that
+            // restart necessarily tears down the link — inherent to moving the device onto a
+            // different network, not a fault to be avoided. Because the save above already
+            // committed the configuration to NVM, losing the link here costs nothing: the device
+            // comes back on the new network with the settings intact. Nothing is sent after this
+            // command, so there is no tail left to drop.
+            Send(ScpiMessageProducer.ApplyNetworkLan);
+
+            // Hold for the module restart window before returning, so the apply is flushed to the
+            // transport rather than left buffered in a connection that is about to go away.
+            await Task.Delay(WIFI_MODULE_RESTART_DELAY_MS, cancellationToken);
+
            // Update local configuration. Static IP fields use null = "leave
            // unchanged" semantics, so only overwrite when the caller provided
            // a value — otherwise we'd clobber the previously known static IP.

Relevance

⭐⭐⭐ High
Repo has accepted fixes tightening cancellation around state changes and preserving consistent state
on cancellation.
PR-#329
PR-#249

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The method checks cancellation once at entry, then sends LAN:SAVE and LAN:APPLY, then performs an
interruptible delay before updating local state; a cancellation during that delay will throw and
skip the in-memory update. Nearby network methods in the same file show the established pattern of
re-checking cancellation immediately before state-changing sends, and a recent accepted bug fix
specifically added a cancellation guard before a LAN:APPLY send in a similar scenario.
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1242-1255]
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1318-1355]
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1364-1377]
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1387-1401]
PR-#324

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`UpdateNetworkConfigurationAsync` sends `LAN:SAVE` and `LAN:APPLY` and then awaits `Task.Delay(..., cancellationToken)`. If the token is canceled during that delay, the method throws `OperationCanceledException` even though the device-side reconfiguration has already been persisted/applied, and it also skips updating `_networkConfiguration`.

### Issue Context
This PR intentionally moved `LAN:SAVE` earlier to make the configuration durable before the WiFi module restart. With the current structure, cancellation during the restart-delay window becomes a misleading outcome ("canceled" while the device has already committed changes).

### Fix Focus Areas
- src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1242-1355]
- src/Daqifi.Core.Tests/Device/Network/NetworkConfigurableTests.cs[532-549]

### Proposed fix
1. Treat cancellation as a **pre-flight** concern for this method:
  - Add `cancellationToken.ThrowIfCancellationRequested();` immediately before the irreversible `Send(ScpiMessageProducer.SaveNetworkLan);` and again before `Send(ScpiMessageProducer.ApplyNetworkLan);`.
2. Once `LAN:APPLY` has been sent, avoid throwing cancellation due to the restart delay:
  - Either `try { await Task.Delay(..., cancellationToken); } catch (OperationCanceledException) { /* best-effort: proceed */ }`
  - Or use a non-cancelable delay (`CancellationToken.None`) after the commit point, depending on desired API semantics.
3. Ensure `_networkConfiguration` is updated even if cancellation is requested during the post-apply delay (since the device operation already occurred).
4. Add a regression test that cancels **during** the delay window and asserts:
  - the method does not surface `OperationCanceledException` after sending apply/save (or, if you choose to keep throwing, asserts local state is still updated and the behavior is explicitly documented).
  - optionally, a test that cancels just before apply/save and asserts apply/save are not sent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Misleading cancel boundary comment~~ ✓ Resolved 🐞 Bug ⚙ Maintainability ⭐ New

Description

In UpdateNetworkConfigurationAsync, the comment immediately before the pre-save cancellation check
says “nothing … applied”, but by that point the method has already dispatched SD/LAN interface
commands, so cancellation is not necessarily side-effect-free on the device’s transient interface
state. This ambiguity can mislead future changes/tests into assuming cancellation before LAN:SAVE
implies no device-side effects at all (vs. the narrower meaning of “no persistence/restart”).

Code

src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[R1323-1327]

+            // Last point at which abandoning the operation is harmless: everything staged above
+            // lives only in the device's runtime settings — nothing persisted, nothing applied.
+            // Past the save below the device has committed, so cancellation stops being a way out.
+            cancellationToken.ThrowIfCancellationRequested();
+

Relevance

⭐⭐⭐ High
Team often accepts fixes for misleading/inaccurate docs/comments to match actual behavior and avoid
ambiguity.
PR-#357
PR-#98
PR-#348

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The cancellation-check comment claims nothing has been “applied” yet, but the method has already
sent SD/LAN interface commands right before that check; the same commands are used by
PrepareLanInterface/PrepareSdInterface to actively change interfaces without any LAN:APPLY/LAN:SAVE,
making the “nothing applied” phrasing ambiguous.

src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1313-1327]
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1433-1468]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`UpdateNetworkConfigurationAsync`’s comment at the pre-`LAN:SAVE` cancellation boundary states that “nothing persisted, nothing applied”, but immediately before that point the method has already sent `SYSTem:STORage:SD:ENAble 0` and `SYSTem:COMMunicate:LAN:ENAbled 1`. Elsewhere in `DaqifiStreamingDevice`, those same commands are used to actively switch/restore interfaces without any `LAN:SAVE`/`LAN:APPLY`, so the comment is ambiguous and may cause incorrect reasoning about whether cancellation is side-effect-free.

### Issue Context
This is about documentation clarity and avoiding incorrect future assumptions: cancellation before `LAN:SAVE` should be described as “no network configuration persisted/applied via `LAN:SAVE`/`LAN:APPLY` (no restart)”, not as “no device-side effects whatsoever”.

### Fix Focus Areas
- src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1323-1327]

### Suggested fix
Rewrite the comment to explicitly distinguish:
- No persistence (`LAN:SAVE` not sent)
- No network-module restart / activation (`LAN:APPLY` not sent)
- But SD/LAN interface commands may already have affected transient runtime state

(Optionally, if the intent really is side-effect-free cancellation, consider moving the cancellation check earlier—before sending SD/LAN interface commands—or documenting/implementing rollback.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Previous review results

Review updated until commit 3da13ad

Results up to commit 4de6f53 ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Canceled despite persisted change~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

UpdateNetworkConfigurationAsync can throw OperationCanceledException during the post-apply
Task.Delay even though it already sent LAN:SAVE and LAN:APPLY, so the device may have durably
changed networks. When that happens, the method also skips updating the in-memory
_networkConfiguration fields, leaving callers with a "canceled" result and stale local state.

Code

src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[R1322-1338]

            Send(ScpiMessageProducer.SaveNetworkLan);

+            // Apply last: this restarts the WiFi module. Over a WiFi/TCP control connection that
+            // restart necessarily tears down the link — inherent to moving the device onto a
+            // different network, not a fault to be avoided. Because the save above already
+            // committed the configuration to NVM, losing the link here costs nothing: the device
+            // comes back on the new network with the settings intact. Nothing is sent after this
+            // command, so there is no tail left to drop.
+            Send(ScpiMessageProducer.ApplyNetworkLan);
+
+            // Hold for the module restart window before returning, so the apply is flushed to the
+            // transport rather than left buffered in a connection that is about to go away.
+            await Task.Delay(WIFI_MODULE_RESTART_DELAY_MS, cancellationToken);
+
            // Update local configuration. Static IP fields use null = "leave
            // unchanged" semantics, so only overwrite when the caller provided
            // a value — otherwise we'd clobber the previously known static IP.

Relevance

⭐⭐⭐ High
Repo has accepted fixes tightening cancellation around state changes and preserving consistent state
on cancellation.
PR-#329
PR-#249

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The method checks cancellation once at entry, then sends LAN:SAVE and LAN:APPLY, then performs an
interruptible delay before updating local state; a cancellation during that delay will throw and
skip the in-memory update. Nearby network methods in the same file show the established pattern of
re-checking cancellation immediately before state-changing sends, and a recent accepted bug fix
specifically added a cancellation guard before a LAN:APPLY send in a similar scenario.
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1242-1255]
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1318-1355]
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1364-1377]
src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1387-1401]
PR-#324

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`UpdateNetworkConfigurationAsync` sends `LAN:SAVE` and `LAN:APPLY` and then awaits `Task.Delay(..., cancellationToken)`. If the token is canceled during that delay, the method throws `OperationCanceledException` even though the device-side reconfiguration has already been persisted/applied, and it also skips updating `_networkConfiguration`.

### Issue Context
This PR intentionally moved `LAN:SAVE` earlier to make the configuration durable before the WiFi module restart. With the current structure, cancellation during the restart-delay window becomes a misleading outcome ("canceled" while the device has already committed changes).

### Fix Focus Areas
- src/Daqifi.Core/Device/DaqifiStreamingDevice.cs[1242-1355]
- src/Daqifi.Core.Tests/Device/Network/NetworkConfigurableTests.cs[532-549]

### Proposed fix
1. Treat cancellation as a **pre-flight** concern for this method:
  - Add `cancellationToken.ThrowIfCancellationRequested();` immediately before the irreversible `Send(ScpiMessageProducer.SaveNetworkLan);` and again before `Send(ScpiMessageProducer.ApplyNetworkLan);`.
2. Once `LAN:APPLY` has been sent, avoid throwing cancellation due to the restart delay:
  - Either `try { await Task.Delay(..., cancellationToken); } catch (OperationCanceledException) { /* best-effort: proceed */ }`
  - Or use a non-cancelable delay (`CancellationToken.None`) after the commit point, depending on desired API semantics.
3. Ensure `_networkConfiguration` is updated even if cancellation is requested during the post-apply delay (since the device operation already occurred).
4. Add a regression test that cancels **during** the delay window and asserts:
  - the method does not surface `OperationCanceledException` after sending apply/save (or, if you choose to keep throwing, asserts local state is still updated and the behavior is explicitly documented).
  - optionally, a test that cancels just before apply/save and asserts apply/save are not sent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Qodo review: UpdateNetworkConfigurationAsync could throw OperationCanceledException from the post-apply Task.Delay even though LAN:SAVE and LAN:APPLY had already gone out, so the device may have durably changed networks. It also skipped the _networkConfiguration update on that path, leaving callers with a "canceled" result and stale local state describing a device that had in fact moved. Cancellation is now a pre-commit concern: - ThrowIfCancellationRequested immediately before LAN:SAVE — the last point where abandoning is harmless, since everything staged until then lives only in the device's runtime settings, unpersisted and unapplied. - After the apply, cancelling ends the restart wait but does not fail the call, and local state is updated either way. Persist-first made this sharper: with both the save and the apply ahead of the delay, a cancel there reported failure for an operation the device had fully committed. Tests: cancel-before-commit asserts neither SAVE nor APPLY is sent; cancel-during-restart-wait asserts the call completes and NetworkConfiguration reflects the committed values. Both fail against the pre-fix code (TaskCanceledException, and SAVE sent despite the cancel). Full suite 1840 passed / 2 skipped on net9.0 + net10.0, 0-warning Release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tylerkron · 2026-07-24T21:38:48Z

/agentic_review

qodo-code-review · 2026-07-24T21:43:46Z

Code review by qodo was updated up to the latest commit 3141551

Qodo review: the comment at the pre-save cancellation check claimed "nothing persisted, nothing applied", but the SD disable and LAN enable immediately above it have already reached the device — Core uses those same commands elsewhere to switch interfaces live. Read literally the comment implies cancelling there is side-effect-free, which could mislead later changes or tests. Reword to separate what cancelling before LAN:SAVE actually buys — nothing persisted, no module restart, device still serving its existing configuration — from what it does not: the staged credentials, the LAN enable flag and the SD disable are already in the device's runtime state, and a later LAN:APPLY from any caller would pick them up. Kept the check where it is rather than moving it earlier, as the review offered as an option. Moving it ahead of the SD/LAN commands would not make cancellation side-effect-free either — the credentials above are staged by then too. Persistence and restart are the boundary that actually matters; the top-of-method check is the only one preceding every Send, and that is now said outright instead of implied. Comment-only; no behavior change. Full suite 1840 passed / 2 skipped on net9.0 + net10.0, 0-warning Release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tylerkron · 2026-07-24T21:45:54Z

/agentic_review

qodo-code-review · 2026-07-24T21:47:51Z

Code review by qodo was updated up to the latest commit e5e5d7e

tylerkron requested a review from a team as a code owner July 24, 2026 21:06

qodo-code-review Bot reviewed Jul 24, 2026

View reviewed changes

Comment thread src/Daqifi.Core/Device/DaqifiStreamingDevice.cs

tylerkron mentioned this pull request Jul 24, 2026

fix(network): reject WiFi reconfiguration over a WiFi/TCP transport (closes #352) #376

Closed

qodo-code-review Bot reviewed Jul 24, 2026

View reviewed changes

Comment thread src/Daqifi.Core/Device/DaqifiStreamingDevice.cs Outdated

Merge branch 'main' into claude/daqifi-hotspot-switching-40d534

3da13ad

tylerkron merged commit ac946fc into main Jul 24, 2026
1 check passed

tylerkron deleted the claude/daqifi-hotspot-switching-40d534 branch July 24, 2026 22:03

This was referenced Jul 30, 2026

fix(mcp): reject over-max sample rates instead of clamping #412

Merged

feat(device): opt-in auto-reconnect and streaming session resume after a drop (closes #379) #418

Merged

Navigation Menu

Uh oh!

fix(network): persist WiFi config before applying it (closes #352) - #391

fix(network): persist WiFi config before applying it (closes #352)#391
tylerkron merged 4 commits into
mainfrom
claude/daqifi-hotspot-switching-40d534

tylerkron commented Jul 24, 2026

Uh oh!

qodo-code-review Bot commented Jul 24, 2026

Uh oh!

qodo-code-review Bot commented Jul 24, 2026 •

edited

Loading

Uh oh!

Uh oh!

tylerkron commented Jul 24, 2026

Uh oh!

Uh oh!

qodo-code-review Bot commented Jul 24, 2026

Uh oh!

tylerkron commented Jul 24, 2026

Uh oh!

qodo-code-review Bot commented Jul 24, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

tylerkron commented Jul 24, 2026

Summary

The premise #376 rests on doesn't hold

Why persist-first is valid (firmware-verified)

Bench validation

Behavior change

Tests

Note

Uh oh!

qodo-code-review Bot commented Jul 24, 2026

PR Summary by Qodo

Uh oh!

qodo-code-review Bot commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

Uh oh!

tylerkron commented Jul 24, 2026

Uh oh!

Uh oh!

qodo-code-review Bot commented Jul 24, 2026

Uh oh!

tylerkron commented Jul 24, 2026

Uh oh!

qodo-code-review Bot commented Jul 24, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

qodo-code-review Bot commented Jul 24, 2026 •

edited

Loading