Say what a control frame during a transfer does #60
Loading…
Reference in a new issue
No description provided.
Delete branch "docs/uf-16-action-3-mid-update"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Section 11 said nothing about a
SYS_WIFI_CONTROLframe arriving while atransfer is running. Documents what the code already does: actions 0 and 2
abandon the transfer, actions 1 and 3 take only the timeout, and action 3's
server is ignored even when it names a different one. Before state 4 a later
action 3 still replaces the server.
No code change. The installed-and-reboot-pending case the ticket also asked for
was already documented by CCS-UF-13. Two tests added, both pinning rules nothing
held before: the different-server frame mid-transfer, and the one that lands
before the transfer starts.
pio test -e nativeis 414 cases; both nodeenvironments and
host_simbuild.CCS-UF-16.
Two of the new paragraph's claims don't match the code.
docs/can-protocol.md:968— "redirecting a running transfer takes an action 0 first" is not enough.disable()callsendSession(), which clears the session credentials, so the action 3 that follows finds none, reports state 5 and leaves the radio off. A redirect needs a fresh session: theBULKcredentials again, then action 3.test_a_session_ended_mid_transfer_can_be_started_againre-holds credentials for exactly this reason.docs/can-protocol.md:964,969— "state 4" isn't the boundary, in either direction, so the rule reads as more precise than it is.WifiManager::loopreports state 2 and callsbeginUpdate()in the same iteration, andNode::loopdrains frames before calling it — so any frame sent in response to the state-2 broadcast already hitsif (updateRunning()) return;. "Before state 4 is reported, a later action 3 replaces the server" therefore over-promises; the window really closes when the node stops connecting, i.e. state 1.updateRunning()also outlives state 4: drop the link mid-transfer andobservedState()reports 5 while the updater keeps retrying, so actions 1 and 3 still only move the deadline there.Both confirmed with a throwaway test against this branch. Key the rule off "while a transfer is running" and drop the "— state 4 —" gloss, then say the server is only replaceable while the node is still connecting.
test/test_wifi_manager/test_wifi_manager.cpp:895— the name says the frame is ignored, but its timeout is taken; only the server and port are dropped. Rename to say that, e.g.test_an_update_frame_mid_transfer_keeps_the_running_server.@ -961,6 +961,14 @@ cannot finish within five minutes, fails of its own accord. Once the boot slothas been switched, nothing cuts step 7 short either: a `SYS_WIFI_CONTROL` framearriving after it is ignored, with no status frame, and the node reboots.A `SYS_WIFI_CONTROL` frame arriving while a transfer is running — state 4 — isobservedState()does not report 4 exactly whenupdateRunning()is true.loop()reports state 2 and callsbeginUpdate()in the same iteration, andNode::loopdrains frames before that, so a frame sent in reply to the state-2 broadcast already findsupdateRunning()true.Key the rule off the transfer running, not off state 4.
@ -964,0 +965,4 @@acted on by action. Actions 0 and 2 abandon the transfer and end the session.Actions 1 and 3 take only the timeout from the frame and leave the transferrunning: action 3's server address and port are ignored, including when they namea different server, so redirecting a running transfer takes an action 0 first.Action 0 also clears the session credentials (
endSession()→credentials_.clear()), so the action 3 after it finds none, reports state 5 and leaves the radio off. Redirecting needs a whole new session — BULK credentials, then action 3 — not just an action 0.@ -964,0 +966,4 @@Actions 1 and 3 take only the timeout from the frame and leave the transferrunning: action 3's server address and port are ignored, including when they namea different server, so redirecting a running transfer takes an action 0 first.Before state 4 is reported, a later action 3 replaces the server the node willOver-promises: the window closes while the node is still connecting (state 1), not when state 4 is reported. See the note above.
@ -890,6 +892,55 @@ void test_a_control_frame_during_a_transfer_does_not_restart_the_join() {TEST_ASSERT_EQUAL_UINT8(1, radio.offCalls);}void test_an_update_frame_naming_another_server_mid_transfer_is_ignored() {The frame isn't ignored — its timeout is taken, only the server and port are dropped. Name it for that, e.g.
test_an_update_frame_mid_transfer_keeps_the_running_server.Nothing left to act on. The new boundary matches
updateRunning():inProgress()isstage_ == Manifest || Image, so it spans the manifest fetch, the image and every retry, and ends atInstalledorFailed— and on success both real nodes setBootControl, so the reboot guard takes the frame from there, which the step 7 sentence above already covers. The link-dropped case is covered too, since the rule no longer keys off a reported state. 414 cases pass, both node environments and host_sim build.