65 lines
3.6 KiB
Markdown
65 lines
3.6 KiB
Markdown
# Node K1 operation identity R4
|
|
|
|
The owner's next Core Fleet UI attempt at 12:19 MSK failed on installed Node
|
|
0.8.1 / K1 0.1.1+private.1. The newly added journal diagnostic recorded
|
|
`action=scan exception=ValueError`. The board still had discovery generation
|
|
zero. Its BlueZ controller was powered and not rfkill-blocked. This was an
|
|
execution failure before discovery, not evidence that K1 was absent.
|
|
|
|
## Reproduced cause
|
|
|
|
The Node protocol requires `op_` followed by 32 lowercase hexadecimal digits.
|
|
The K1 OperationJournal accepts a UUID, optionally prefixed by `op-`. Passing
|
|
the Node ID unchanged fails in device_lifecycle._identifier before any BLE
|
|
call. R3 corrected the missing runtime fence but its service stub hid this
|
|
second boundary mismatch. The new regression reproduced the exact ValueError
|
|
with the real NodeBridge, facade, compatibility service and operation journal.
|
|
|
|
NodeBridge now translates the host ID into the plugin UUID format. The mapping
|
|
is deterministic and preserves all 128 bits. Host IDs remain unchanged in the
|
|
Go broker, durable Node journals and HTTP responses. The plugin's validators,
|
|
LAB callers and lifecycle authority are unchanged. Connection attempt and
|
|
recovery IDs are projected back to host IDs so continued UI observation can
|
|
still match the exact request after the Wi-Fi acknowledgement.
|
|
|
|
The same conversion covers scan, provision, verify, START and STOP. The
|
|
acquisition prepare child uses a deterministic UUID derived from the host
|
|
intent, distinct from its START operation. It no longer appends an invalid
|
|
`_prepare` suffix to an operation ID. Repeated intent IDs reach the same journal
|
|
row; no random replacement IDs, automatic provisioning replay or migration of
|
|
old unknown operations were introduced.
|
|
|
|
## Error evidence and UI
|
|
|
|
An invocation failure reads only its exact existing plugin journal row. A
|
|
recorded scan failure reaches the caller as failed; an exception before any
|
|
row exists remains an unconfirmed execution. Neither is a successful empty
|
|
search. Both produce a Bluetooth search error in the shared enrollment UI,
|
|
while a confirmed zero-candidate result still displays K1 not found. Search
|
|
failures do not display the Wi-Fi connection notice.
|
|
|
|
Unexpected worker failures log admitted action, exception class and source
|
|
function/line locations only. Exception text, source text, local variables,
|
|
request payloads and credentials are excluded.
|
|
|
|
## Validation and limits
|
|
|
|
The scan regression keeps the actual service, journal, BLE arbiter and scanner
|
|
logic, replacing only BleakScanner's OS radio endpoint. It verifies successful
|
|
discovery and a failed radio start, correct host result correlation, and one
|
|
radio invocation when the exact command is repeated. Acquisition IDs are
|
|
checked against the actual OperationJournal. Projection does not mutate the
|
|
plugin's native state. Frontend tests distinguish failed, rejected, unknown
|
|
and confirmed empty scans and retain network/bootstrap/recovery regressions.
|
|
|
|
Focused Python bridge, installer, Fleet enrollment, BLE scanner and operation
|
|
journal suite: 73 passed. Core frontend suite: 789 passed, no failures or skips.
|
|
Build and installation acceptance is recorded below when completed.
|
|
|
|
Release versions are Node 0.8.2 and optional K1 0.1.2+private.1. Existing private
|
|
release bytes and application material are retained. This is a Node adapter
|
|
correction; no Rerun profile, protocol frame, MQTT recovery state machine or
|
|
shared lifecycle validator was modified. Physical Bluetooth discovery, Bridge,
|
|
live camera/LiDAR and interruption recovery still require fresh-cache UI
|
|
acceptance. No agent CLI hardware command is part of this test.
|