Offline PWA, idempotency, and local data cleanup

A large day on the client project (NDA), with many parallel sessions converging on one question: how to make an offline-first app reliable enough for real use.

There were many workspaces, but the work grouped into a few themes.

Client project (NDA)

Offline, sync, and idempotency

The main thread was strengthening the contract between frontend, backend, IndexedDB, and the offline queue. I reviewed registration idempotency, the key used by the frontend, retry behavior for pending operations, and the link between local data and server-confirmed data.

I also moved forward with the decision to keep one consolidated migration while there is no real production load yet. At this stage, it is better to reduce history noise and make the initial database state clear.

PWA and mobile UX

Another major part of the day was the PWA. The app gained a richer manifest, guided install behavior, wake lock, badging, and install adjustments across platforms. I also reviewed the sticky mobile header, installed-app behavior, and lag reported while using the app as a PWA.

Local data cleanup became a support tool: a Settings button to clear IndexedDB when the local environment gets inconsistent or a test needs a clean start.

Backend and domain model

On the backend, I consolidated Pino logging, test mock fixes, idempotency, and safer handling of sensitive data in logs. I also kept separating concepts that had drifted together, such as the sequential report number and the manually entered work order.

tgmarinho-ai-website

I reviewed the post about idempotency in APIs, distributed systems, and offline-first flows. The text became more anchored in the real problem: retry is not the only risk, because the user, the offline queue, or a webhook can also try to repeat an operation that was already processed.

The day was about removing ambiguity: in the database, in the queue, in the PWA, and in the text that explains why this matters.