I'm parked on you

Pick an option on each card and press Done; your answer goes straight back to the session. The raiser's pick is marked. "I'm not sure" and "Take it to the engineering bridge" are real answers.

1

In plain terms. Two old AppFolio sync-health records are stuck on error messages from weeks ago and are making the system cry wolf about Situs Group and Western Slope, even though both are syncing fine right now — can I delete those two stale records?

The full question, as raised

PMS_CONNECTION_HEALTH rows frozen on job keys retired by a schedules.json class regroup: Situs Group (org_a3376147#situsgroup) JOB#rental_applications,guest_cards,guest_card_messages froze 2026-09-29 (last error AppFolio 429), superseded 2026-10-02 by PR #15309 which folded it into JOB#work_orders,rental_applications,guest_cards,guest_card_messages — that bundle is healthy today (0 failed, ticked within the hour). Western Slope PM (org_c42d9150#westernslopepm) JOB#balances froze 2026-09-13 (last error AppFolio account budget exhausted) at the original class cutover (PR bf01a9a1997), superseded by JOB#balances,occupancies,lease_states,prospect_conversions — also healthy today. assessConnectionHealth's DEAD/PARTIALLY-DEAD checks (src/lib/domain/pms/sync-connections.ts) grade every row regardless of whether its key is in expectedHealthJobCadences (only the STOPPED check filters on that), so a retired row that can never be rewritten again alarms forever on its frozen last-3-ticks. docs/runbooks/ops.md already names the fix: 'fires it until they are deleted.' There is no existing script for this (only set-pms-health-orphan-prune.ts, which is for orgless connections, not retired job keys) and deleting prod DynamoDB rows is a hard stop for me without your go.

Delete the 2 stale rows nowthe raiser's pick Leave them as-is I'm not sure — go find out Take it to the engineering bridge

Why, and what was tried

The session raising this recommends: Delete the 2 stale rows now
They can never be rewritten again (their job keys are retired by the regroup), so they will re-alarm forever otherwise, and both connections are confirmed healthy under their real current job bundles as of this run.
Tried first, unsuccessfully: Read both companies' PMS_CONNECTION_HEALTH rows directly from propflow-prod, cross-referenced lastTickAt against lambda/appfolio-sync/schedules.json and its git history (PR #15309, PR bf01a9a1997) to confirm the frozen rows' job keys were retired by known regroups and that the current equivalent bundles are green today; confirmed no cleanup script exists for this case and that deleting prod DynamoDB rows is outside my action charter without approval.

b2ff0fa6 is parked on this.

Pick an option above, then press Done.