Confirm That a Passing PCB Test Result Was Actually Saved

A station can display PASS while its result upload fails. If the operator removes the board immediately, production may continue without the evidence needed for release or traceability. Define when a completed measurement becomes an accepted, stored test record, and make storage failures visible.

The SQLite atomic commit explanation describes how changes within a transaction are treated as a complete unit. That principle helps organize related result fields, but a database transaction does not automatically include an external waveform file, a remote server, or every step of a station’s workflow.

Identify the storage boundary

List the artifacts needed for a complete result: unit identity, attempt identity, step outcomes, recipe identity, and required attachments. Decide where the authoritative record resides. If the station temporarily stores data locally before uploading it, distinguish local capture from confirmed central receipt.

Assign the attempt identifier before acquisition or at another defined point that survives retries. Use the same identifier when retrying the upload of an existing attempt. Creating a new test attempt for each network retry inflates counts and makes an unchanged result appear to be repeated physical testing.

Design visible completion states

Define the permitted board disposition for each state. Some operations may allow a controlled offline queue; others may require holding the unit. The policy should be explicit, with ownership for reconciling pending records and a limit on unresolved work appropriate to the process.

Test interruption and recovery

1. Interrupt network access in a controlled validation environment.
2. Restart the application while an upload is pending.
3. Repeat a request after its acknowledgement is lost.
4. Verify that incomplete attachments remain visible.
5. Reconcile local and central attempt counts after recovery.

Check the stored record through an independent retrieval path, not only the same screen that initiated the write. Confirm that the measurement values and required metadata are present and that repeated upload requests do not create conflicting duplicates.

Retain recovery history separately from the original measurement time. A delayed upload should not imply that the board was tested later. Review pending queues routinely and alert the responsible team when recovery stops progressing. The retest history guide addresses actual repeated testing; upload retries must remain distinguishable from those physical events.