SQLiteOrderOutbox.mjs

Source file: apps/mobile/src/order-store/SQLiteOrderOutbox.mjs

Module: app-mobile

Size: 69 lines

SHA-256: 331bab2a37bedf60df54eab4a3878d442e8c02793ec807a4858463f495efecde

Responsibility

Runs the real customer UI with native or fail-closed device and backend services; no simulated success.

Declared entry points

• without — source line 3.
• SQLiteOrderOutbox — source line 6.
• idempotency_key — source line 30.
• lines_json — source line 31.
• row — source line 38.
• saved — source line 44.

Imports and dependencies

No direct import declarations detected in this file.

Behaviour and audit locations

• Line 15: idempotency_key TEXT NOT NULL PRIMARY KEY,
• Line 30: const idempotency_key=globalThis.crypto.randomUUID();
• Line 32: await this.db.execute('INSERT INTO hslg_order_outbox (idempotency_key,venue_id,table_number,lines_json,state) VALUES (?,?,?,?,?)',
• Line 33: [idempotency_key,venue_id,table_number,lines_json,'draft_pending']);
• Line 34: return idempotency_key;
• Line 37: if (!/^[0-9a-f-]{36}$/i.test(key)) throw new Error('Invalid idempotency key.');
• Line 38: const row=await this.db.get('SELECT * FROM hslg_order_outbox WHERE idempotency_key = ?', [key]);
• Line 50: await tx.execute("UPDATE hslg_order_outbox SET state = 'uncertain' WHERE idempotency_key = ? AND state = 'draft_pending'",[key]);

Durable local draft semantics

This class requires an injected native SQLite driver exposing execution, lookup and atomic transaction operations. It creates hslg_order_outbox records keyed by a random UUID and limits venue, table and line formats before storage. Draft records track pending, uncertain and server-saved states; the code must reconcile requests by their original idempotency key instead of retrying with a fresh key. This module does not process payments and deliberately has no localStorage fallback. It is not a working native offline store until an approved SQLite driver and on-device recovery tests exist.

Relationship to the system

This page is the file-level source reference, not the architecture rationale. Read the module explanation, the corresponding architecture decision and user guide before changing behaviour. Names and line locations above are extracted from this exact source version; they are reference points, not proof that an external service or a phone feature works.

Change verification

Review the entry points and errors in this file, then run the module’s associated tests, source dependency gate, history gate and documentation coverage check. If the file changes an API response, user interaction, data model, deployment or third-party dependency, revise those human explanations and disaster recovery/licensing when relevant. Do not infer actual native or external API operation from source presence.