Add structured logging on TVM pairing failure paths

[polylane]

Generated by Polylane Autofix after Ankcorn/Shortcut was connected.

Lineage		Status
Repository	Ankcorn/Shortcut	connected
↳ connected	Autofix fix_fc97e5…	succeeded
↳ opened	this PR	open

The TVM pairing Cloud Function silently swallowed push-notification delivery errors — the FCM callback received an error parameter but never logged it. The mobile barcode scanner logged fetch failures with no context about which machine was being paired. This adds structured logging with machine and user identifiers on both the server-side notification delivery path and the mobile pairing error path so operators can correlate pairing failures to specific devices.

Why this matters

• Server-side FCM delivery failure (backend/functions/index.js): When a push notification fails to deliver, the server swallowed the error silently — no log at all. An operator investigating a “machine won’t pair” report had nothing in the logs to point at FCM. Now the failed delivery logs tvmId, userId, and error.message, so the incident question “did the notification to this machine ever arrive?” is answered directly from logs instead of requiring a queue replay. - Mobile pairing fetch error (mobile/pages/Camera.js): The catch block logged the error object alone — no machine identifier. An operator seeing the error could not tell which TVM was being paired. Now it includes tvmId (the scanned barcode), so a failed pairing on a specific machine is traceable.

What changed

• backend/functions/index.js — Replaced console.log(body) with a structured log (operation, tvmId, userId); added a structured error log in the request.post callback that previously ignored its error argument entirely. - mobile/pages/Camera.js — Added operation and tvmId (the scanned barcode data) to the console.error in the fetch catch block so a failed pairing attempt is correlated to a specific machine.

Validation

• eslint backend/functions/index.js — 0 errors (1 pre-existing prefer-arrow-callback warning unchanged)

Root cause, safety reasoning, and scoping notes

Root cause

The FCM callback already received error as a parameter but discarded it — adding a log statement there is purely additive. The mobile catch block already called console.error(error); we now pass context alongside it. No behaviour changes, no new code paths.

Why it's safe

Changes are additive log statements only — no control flow, error handling, or response behaviour is altered. The FCM callback still returns the same response; it now logs the error it was already receiving but ignoring. The mobile catch block still re-throws; it now logs with context first. No new dependencies, no schema or interface changes, no boot-path additions.

Out of scope / follow-ups

• tvm/firebase-messaging-sw.js:7 — background message handler has a console.log but no error path to add context to; left untouched as a service worker with no existing structured-logging convention. - tvm/choices.html:107 — debug console.log in client-side UI code, not an operator-facing failure path; left untouched.

2 files changed (+22/-6)

• backend/functions/index.js: modified, +17/-5
• mobile/pages/Camera.js: modified, +5/-1

---

Generated by Polylane.

[polylane]

Warning

Polylane could not verify the production impact of this pull request.

Checked both changed files against the Cloudflare account's 18 workers — none run this code (it's a Firebase Cloud Function and a React Native component). The changes are additive structured logging on error paths; no control flow, response behavior, or error handling is altered.

View the full analysis →

Polylane could not find the cloud resources this repository manages, so this review looked at the entire cloud account. Connect this repository to its resources and the next review will focus on exactly what this code deploys to.

_{Polylane analysed c648f48 for production impact.}