Attik job cancellation silently skips Spectora notification when _spectoraJobId is absent

Objective

• Ensure staff are informed when an Attik job cancellation cannot be forwarded to Spectora due to a missing _spectoraJobId.
• Prevent inspectors from being dispatched to properties for jobs that were cancelled in Attik but never communicated to Spectora.

Background

• When an Attik job is cancelled, inspectionStream.ts calls cancelBarebonesSpectoraJob, which attempts to fire a cancel to Spectora using _spectoraJobId.
• If that field is absent or null, the function silently exits with only a server-side console log — no error is surfaced to staff, no retry is attempted, and there is no confirmation that Spectora was notified.
• This means an inspector can remain scheduled in Spectora for a job that has been cancelled in Attik.
• This is the likely contributing factor in the SWF – 101 Edward Ave incident (ATT-1930) — the frontend crash may have also prevented the cancel API from being called at all, but even if the cancel succeeded in Attik, a missing _spectoraJobId would have caused the Spectora notification to silently drop.
• This scenario occurs when the barebones Spectora sync (syncBarebonesSpectoraJob) has not yet completed or failed for a newly created Attik job at the time of cancellation.

Repro Steps

1. Create a new Attik job. Before the barebones Spectora sync completes (or with sync disabled/failing), cancel the job via POST /inspection/:id/cancel.
2. Check the inspection record in MongoDB — confirm status: 'cancelled', canceledBy, and canceledAt are set.
3. Check _spectoraJobId on the same record — confirm it is absent or null.
4. Expected: Staff are informed the Spectora cancel could not be sent, or the cancel is queued for retry once _spectoraJobId is populated.
5. Actual: cancelBarebonesSpectoraJob exits silently. The inspector remains scheduled in Spectora with no indication to staff that Spectora was not notified.

Verification checklist for eng

• Query the automation event history for the inspection — confirm no cancel attempt was logged against Spectora.
• Confirm the inspector's Spectora calendar still shows the job active after the Attik cancellation.
• Check server logs for the skip reason=no_spectora_job_id log line.

Product Decisions

Locked

1. Bug. A silent skip on Spectora cancel notification is a real operational risk — it can result in an inspector being dispatched to a cancelled job.
2. Staff must be informed when a Spectora cancel could not be sent so they can manually notify Spectora or the inspector.

Open

1. What is the right failure mode — a visible warning in the UI at time of cancellation, a follow-up notification once the gap is detected, or a retry queue that fires when _spectoraJobId is eventually populated?
2. Should _spectoraJobId always be present by the time a job could reasonably be cancelled? If so, is there a gap in the barebones sync timing that should be addressed upstream?

Scope

Backend

• attik-backend/src/util/functions/spectora/syncBarebonesSpectoraJob.ts — cancelBarebonesSpectoraJob function; replace silent skip with an observable failure path (error surfacing, retry queue, or staff notification)
• attik-backend/src/events/streamHandlers/inspectionStream.ts — becameCancelled handler; confirm the cancel result is captured and any failure is actionable

Out of scope

• Frontend workorder crash (tracked in ATT-1930)
• Spectora-native job sync overwrite (separate concern, not relevant to Attik job type)

References

• ATT-1930 — frontend workorder crash (related incident)
• attik-backend/src/util/functions/spectora/syncBarebonesSpectoraJob.ts
• attik-backend/src/events/streamHandlers/inspectionStream.ts
• Inspection 1008599797