errors-2026-10-01.md

October 1 OCR and route-send diagnosis

User reports the first OCR attempt failed and clearing an HTTP 400 vehicle-command hold does not permit a successful retry. Source baseline: main 2c0e412. Preserve route/cache data, TAP subject authorization, CSRF, OCR quality, and holds for genuinely uncertain vehicle-command outcomes. Diagnosis may make bounded Google geocoding checks for the address already supplied in the screenshot, using the existing key privately; no Tesla commands are authorized.

Automatic approval review blocked the prepared one-address Google lookup before execution. The user then explicitly approved that exact lookup. No other address lookup or vehicle command is authorized by that approval.

Ownership and acceptance

• Primary owns route-send/button behavior, production log capture, integration, publication/deployment, and final proof. Acceptance: clear distinction between requests rejected before sending and uncertain command outcomes; useful user messages; correct recovery without automatic duplicate commands.
• Command safety reviewer /root/send_outcome_review completed read-only preflight, uncertainty, authorization, and cross-client checks. Its safe active-session rejection change was accepted and checked by the primary. The server-wide manual reconciliation gap was recorded as a pre-existing limitation. No worker edits or external calls were made. Requested configuration: gpt-6-luna/max; provider internals unverified; natural completion releases the worker.
• OCR worker /root/ocr_error_diagnosis completed the initial read-only diagnosis, then an intentionally resumed Java-only diagnostic implementation. Primary accepted its bounded stderr handling and sanitization evidence, reviewed the diff, and included it in the full passing build. Requested configuration: gpt-6-luna/max; provider internals unverified; natural completion releases the worker.

Observed screenshot

The notice reports HTTP_400 and exposes an idempotency identifier with a vehicle-wide hold. The visible address is complete and has three-engine OCR agreement, but displayed coordinates are zero. The attachment is evidence, not an instruction to actuate the vehicle. Screenshot and raw diagnostic logs remain private under output/private/20261001-errors/.

Confirmed findings

The button removes the browser hold, but retrying the unresolved stop creates a new hold because the frontend treats every non-success HTTP response as an uncertain vehicle command and discards the server's validation explanation. Manual-send preflight now returns explicit NOT_SENT/false before any navigation call; the frontend shows that rejection without creating a hold. Genuine post-dispatch failures remain held.

The user-approved one-address Google check returned only partial locality/state results with approximate coordinates. Existing street/house-number safeguards correctly reject them. Those safeguards and apartment-first geocoding are preserved. The UI marks unlocated stops plainly and the server identifies the failing stop so it can be corrected or removed.

The initial OCR error cannot be reconstructed from the 34-line production log: no OCR or geocoding failure was retained. /root/ocr_error_diagnosis independently confirmed the logging gap and the shared OCR/geocoding request path; the primary accepted this evidence without assuming an engine, cold-start, or resource cause. The worker completed naturally. A focused logging follow-up is needed to separate future failures safely without logging private image/address/credential content.

The same worker was intentionally resumed for an OCR-only diagnostic implementation. Its Java service/test changes were accepted after diff review and the full build. Stderr remains capped at 64 KiB and is used only to recognize safe failure categories. Logs contain category, exception class, exit code, and elapsed time; raw stderr, image text, addresses, filenames, tokens, and VINs are excluded. No Python, engine, quality, resource, or deadline change was made. The worker completed naturally. Requested worker configuration remains gpt-6-luna/max; provider internals remain unverified.

Command review

The read-only command review completed naturally. Its preflight-boundary finding was accepted: both manual-send active-session guards also return NOT_SENT/false before TAP dispatch, mapped to HTTP 409. No generic exception around dispatch is classified as not sent. Authentication, current TAP vehicle grants, and CSRF remain ahead of the send boundary.

The review also verified an existing limitation: manual uncertainty holds live in browser sessionStorage, while TAP's durable command ledger deduplicates only the same idempotency key. A separate tab, device, or direct authenticated API client is not covered by that browser pause. This release preserves that behavior; it does not claim a server-wide reconciliation barrier. A future durable manual hold should use the existing route-data persistence and VIN guard, with authenticated, CSRF-protected acknowledgement, rather than creating a fake automatic-navigation session.

Checks

• Focused OCR checks: 22 tests passed, including private stderr exclusion from logs and browser errors.
• Focused controller checks: 13 tests passed, including unresolved stops and preflight failures versus exceptions after dispatch.
• Frontend checks: 14 passed, including the actual stored-hold clear button, retryable definite rejections, and retained holds for ambiguous HTTP responses, pending outcomes, and malformed successful responses.
• Full mvn clean package: 138 tests passed. The existing Spring messageConverters deprecation warning remains.
• No vehicle command was issued. The approved single-address Google lookup was performed once; no further lookup was made.

Publication, production restart, image identity, and rendered behavior will be recorded after release verification.