Smart Audit

Context & problem

Smart Audit submits an inspection and its assignment as two separate requests. When the second one failed — a dropped connection, or API validation rejecting it — the first had already been saved. The record was left half written: an inspection with no assignment, and a status that no longer described reality.

Users & team

Auditors submitting from mobile, often on unreliable connections. A failure partway through a submission had to cost them as little of their work as possible.

Personal contributions

• Preserved local form state and wrote a recovery marker when a submission step failed.
• Refetched the inspection and assignment records to determine which step had already succeeded.
• Retried only the failed step, using the latest lock_version.

Architecture & decisions

Vue.js and Quasar on the frontend, Golang on the backend.

Recovery reads the server’s state rather than trusting the client’s. Both records are refetched and reconciled before anything is retried, so the retry is based on what was actually saved, not on what the device believed it had sent.

Key features

• Form progress survives a failed submission step.
• Inspection and assignment records are reconciled before any retry.
• Only the step that failed is retried, against the current record version.

Challenges & solutions

Retrying is the obvious response to a failed step, and the dangerous one. Between the failure and the retry the record may have moved — edited by someone else, or changed by an earlier request that landed late. A blind retry would overwrite newer data.

Sending the latest lock_version with the retry closes that window: the write is rejected if the record changed after it was read. Combined with refetching both records first, the retry only ever completes the step that is genuinely still missing.

Results

Only the failed step is retried, so a partial save no longer forces the user to resubmit the whole form.