Repository navigation
Discovery, transfer error, cancel and offer-before-supervising scenarios - #557
Merged
Merged
Conversation
chrysh
force-pushed
the
followup-itest
branch
from
October 10, 2026 19:18
2b51c26 to
a02e99a
Compare
21 tasks
chrysh
force-pushed
the
followup-itest
branch
2 times, most recently
from
October 10, 2026 20:17
2d53479 to
76edbf2
Compare
The test agent sent QueryDeviceIdentifiers first and assumed the device spoke firmware update 1.3.0. It now asks: GetPLDMTypes for both halves of the protocol, GetPLDMVersion for the firmware-update version, and GetPLDMCommands for that version's command set, checked against the ten commands the sequence uses in either direction. The start-order retry moves to GetPLDMTypes, which is now the first request the agent sends. Assisted-by: Claude Opus 5
A communication failure had no scenario: every negative so far arranged a bad image or a refusal. The agent now answers one RequestFirmwareData with an error completion code, so what goes wrong is the answer to one request rather than the image. The device aborts the transfer. The device names the failure by counting chunks: it asked for one more than it was given, nothing was activated, and its own content check never fired. A run that ends any other way fails the scenario rather than passing it. Assisted-by: Claude Opus 5
The cancel arc had no scenario: the state machine answers `Event::UpdateCancelled` by dropping what was staged, and nothing drove it. The agent now sends CancelUpdate two chunks in, far enough that the device is transferring rather than still answering the offer. The device reports `Cancelled` and waits there. It is not running the update at that point, so it serves the RoT's channel from the same call that is waiting, which is what the other decision points already do. The RoT drops the job, settles in Ready and acknowledges, and only then does the device let the session go. Not a failure, so the scenario does not pass on one: nothing was activated and the acknowledgement has to have arrived. Checked by withholding it, which fails the run at the device. Assisted-by: Claude Opus 5
The gate that refuses an update while the machine is not supervised had no scenario. The device now offers one to a RoT that never powered on its chain, and the RoT answers Busy. Busy rather than a policy violation, because the two are different answers to the device: one says not now, the other says not this image. The refusing scenario next door covers the second, so this one asserts the reason rather than the refusal. `accept_update` returns the reason it refuses with instead of a bool, so the reason is decided where the cause is known rather than at the call site. Assisted-by: Claude Opus 5
chrysh
force-pushed
the
followup-itest
branch
from
October 10, 2026 20:41
76edbf2 to
a438ca1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four additions to the QEMU integration test suite, bringing it to eleven
scenarios and twenty-two targets.
GetPLDMCommands before it offers anything, and checks the reported
version and command set against what it goes on to use. The start-order
retry moves to GetPLDMTypes, which is now the first request it sends.
pldm_update/transfer_error. The agent answers oneRequestFirmwareData with an error completion code, so what goes wrong is
the answer to one request rather than the image. The device aborts the
transfer and nothing is activated.
pldm_update/cancel_mid_transfer. The agent withdraws two chunksin. The device says so and waits; the machine drops what was staged,
settles in Ready and acknowledges, and only then does the device let the
session go.
pldm_update/offer_before_supervising. The offer reaches a RoT thatis supervising nothing, and is refused as busy rather than on policy.
The two are different answers to the device, and the refusing scenario
next door covers the other one.
Each negative was checked by arranging the opposite: the version floor
raised to 1.4.0, the error injection removed, the acknowledgement
withheld, the refusal turned off. Check that offer_before_supervising
asserts the reason (Busy, not PolicyViolation), not just the refusal.