Bug: PriorityLab appointment not appearing in portal despite successful resync (Charleston)

Objective

• Ensure that when a PriorityLab sync completes and Attik shows a _priorityLabPropertyId, the corresponding appointment is actually visible in the PriorityLab portal.
• Prevent silent sync failures where the integrations tab reports a property ID and a recent sync timestamp but no appointment exists on the vendor side.

Background

• Rein Manalad reported that order 1008600662 for Charleston Home Inspection does not appear in the PriorityLab portal despite the following being confirmed:
• The integrations tab on the work order shows a _priorityLabPropertyId under the PriorityLab Breeze integration.
• The inspector shown matches the inspector on the work order.
• A last-synced timestamp of 6:16 was present; Rein manually resynced on June 24 — the appointment still does not appear in the portal.
• The inspector has an active profile in the PriorityLab portal.
• The PriorityLab integration is enabled at the service level.
• A property address search in the PriorityLab portal returns no results for this order.
• This symptom profile matches ATT-1669 exactly: Attik shows a property ID (potentially from a prior sync) while the most recent sync either failed silently or wrote to the vendor without the appointment being findable.
• ATT-1669 was resolved in PR #513 on May 26, 2026. This report suggests the fix may not cover all cases, or a new edge case exists specific to the Charleston instance configuration.
• PostHog error tracking was checked on June 24, 2026 — no active or recently resolved issues matching PriorityLab sync errors were found. The failure is not generating a frontend-visible exception, which is consistent with a silent backend sync failure recorded in priorityLab.lastError rather than a thrown error reaching the client.
• This is a Credibility risk — a mold test appointment that doesn't appear in the lab portal is an operational miss, not just a display issue.

Product Decisions

Locked

1. New issue — ATT-1669 was marked Done; this is filed as a separate report to keep history clean.

Open

1. Root cause — Backend logs for order 1008600662 need to be pulled to determine what CreateUpdateAppointment actually returned on the June 24 resync. Until then, whether this is a regression of ATT-1669 or a new edge case is unconfirmed.
2. Charleston-specific config — It is unknown whether any configuration difference in the Charleston instance (inspector profile setup, service-level integration config, etc.) exposes a sync path not covered by the PR #513 fix.

Scope

Backend

• attik-backend/src/util/functions/priorityLab/syncPriorityLabAppointment.ts — primary sync path; check whether the June 24 resync attempt recorded a priorityLab.lastError or cleared it as a success.
• attik-backend/src/util/functions/priorityLab/priorityLabApi.ts — parseVendorResponse and createOrUpdateAppointment; verify the fix from PR #513 handles all response shapes being returned for this order.
• attik-backend/src/util/functions/priorityLab/priorityLabIntegrationCheck.ts — added as part of or around PR #513; confirm whether the integration check gate is passing or blocking sync for this order.
• attik-backend/src/util/functions/priorityLab/buildPriorityLabPayload.ts — confirm payload being sent on resync is correctly formed for this inspector/service combination.
• attik-backend/src/events/bullmq/priorityLabQueues.ts — check BullMQ job logs for order 1008600662 for any failure state, retry exhaustion, or silent success.
• attik-backend/src/events/streamHandlers/inspectionStream.ts — verify the resync trigger path routes through the same queue/worker as the original sync.

Frontend

• attik-frontend/src/app/tools/inspections/[id]/components/integrations/PriorityLab.tsx — the integrations tab display; the property ID shown may be stale from a prior successful run if lastError is not being surfaced clearly.
• attik-frontend/src/app/tools/inspections/[id]/components/InspectionIntegrations.tsx — confirm whether sync error state from priorityLab.lastError is being surfaced to the user on resync.

References

• Work order: https://www.attik.ai/inspections/1008600662
• Related: ATT-1669 — PriorityLab sync fails when CreateUpdateAppointment response omits confirmation (Done, May 26)
• Related: ATT-1505 — Two inspections sharing one _priorityLabPropertyId (Done, May 26)
• PR #513: Attik-Field-Service-Solutions/attik-backend#513