A Result Upload Fails After the Board Passed: Do Not Release an Untraceable Unit
If the board passes but its result upload fails, preserve the test result locally and keep release eligibility separate from the physical test outcome. Reconcile the same immutable attempt with the result service; do not rerun the hardware merely to obtain a new upload. Where traceable acceptance is required, a missing or mismatched receipt remains a release hold.
This article defines an original station/result-store contract. Six checks were executed using Python 3.12.14 and SQLite 3.53.1 in owned local files that simulated a station and receiver. There was no network upload, factory database change, physical test or shipment decision.
Separate four pieces of evidence
Track the physical test outcome, the station’s saved attempt record, the receiver’s accepted record and the release authorization. They can advance at different times. A successful instrument reading does not prove that its identity and conditions were retained, and a network response does not necessarily mean the service durably accepted the intended record.
Define what the service’s receipt means. It should bind the attempt identity, unit identity and exact accepted payload or digest under a documented persistence contract. A generic HTTP success page or transport acknowledgement is too weak if it can precede validation and storage.
The NASA verification handbook emphasizes retaining the tested configuration, results and discrepancy context. For a production station, that evidence must remain associated with the actual unit through local storage, transfer and final disposition.
Commit the attempt before making it uploadable
Create a unique attempt identity and immutable payload containing the unit, test/configuration revisions, observations, outcome and required provenance. Record an explicit completion status. A partially assembled payload must not become a valid pass because the uploader found its filename.
Store the payload and its pending-transfer state through a qualified local persistence mechanism. Check every write/commit result. If local persistence fails, report a record-storage failure and apply the approved unit hold; do not silently fall back to volatile memory while displaying a complete pass.
SQLite’s transaction documentation describes explicit commit/rollback and possible busy/error outcomes. A commit request is not something the caller may assume succeeded without checking. The example uses SQLite to exercise record logic, not as a claim that any storage device or configuration automatically meets factory durability needs.
Reuse the attempt identity on a transfer retry
Retry the same payload under the same attempt identity. If the receiver already accepted it but the receipt was lost, an identical replay should return the original accepted relationship rather than create another physical-test event.
Define a conflict separately: the same attempt identity arrives with different unit or payload content. Hold that case and preserve both observations for investigation. Do not implement replay handling as an unconditional overwrite or as “duplicate key means success” without comparing the associated content.
A digest helps compare payload bytes but does not authenticate the sender or authorize release. Use the deployment’s approved authenticated transport and access control. Keep credentials out of ordinary diagnostic exports and send only the data needed for traceability.
Read the executed two-file simulation
The fixture wrote a synthetic U1/T1 pass as attempt A1 into a station database, committed it and reopened the file cleanly. It then recorded A1 in a second local database representing the receiver, deliberately omitting the receipt update at the station.
| Executed control | Observed model result |
|---|---|
| Clean close/reopen after station commit. | Original payload remained present and pending. |
| Receiver acceptance with receipt omitted locally. | Station remained pending rather than assuming completion. |
| Identical replay of A1. | Receiver retained one accepted row and returned the same binding. |
| A1 replayed with a changed digest. | Conflict rejected; accepted content was not replaced. |
| Receipt with the wrong unit. | Station refused confirmation. |
| Matching receipt. | Station confirmation persisted across clean reopen. |
All six checks passed. The “lost receipt” was a deliberate omitted local update, not a measured network fault. The fixture did not test concurrent receiver races, process termination, power loss, disk-full behavior or backend replication.
Keep persistence claims within their tested scope
SQLite’s atomic-commit explanation describes journaling and storage flushes as part of its transaction mechanism. Actual guarantees depend on the selected mode, operating system and storage behavior. A clean close/reopen test cannot establish survival of an abrupt power failure.
Qualify the station’s real storage stack with supported fault tests and an explicit retention policy. Preserve enough capacity for bounded outages, expose pending age and count, and define what happens before the queue is full. Do not discard the only traceability record to allow more units through.
If offline release is permitted, it needs an approved alternate evidence and authorization path. Do not invent that exception during an outage. The normal service being unavailable does not change the product’s traceability requirements.
Recover without creating a second physical history
On station restart, enumerate committed pending attempts and reconcile each with the receiver. Preserve their original unit and test identities. A restart-generated upload identifier can exist, but it must remain subordinate to the original physical attempt identity.
If the receiver reports a matching record, save and validate its receipt locally. If it reports no record, retry under the same idempotency contract. If the response is ambiguous or conflicting, retain a hold rather than guessing whether the earlier upload succeeded.
A hardware rerun is appropriate only when the test evidence itself is missing, invalid or requires repetition under the approved process. If performed, it creates a new attempt linked to the earlier one. It must not overwrite the original pass simply because transfer recovery was inconvenient.
Make the operator’s status unambiguous
Display separate states such as “test passed, record pending,” “record conflict” and “eligible for release review.” The release mechanism must consult the same authoritative state rather than relying on a green test indicator that ignores transfer status.
Acceptance requires matching physical-unit evidence, a retained attempt and the required storage receipt, followed by the authorized release decision. The deliverable is a restartable result-transfer state machine with duplicate and conflict controls. It preserves a useful pass without turning an upload outage into either needless reflashing or an untraceable shipment.
