Guest cards stuck retrying a repair: not happening today
Task appfolio-sync-reads, board row 8 (p6-heal-loop). Issue #16738. Read-only investigation, 2026-10-05. No production data was changed.
Answer
The suspected loop (a failed repair clears the card's fingerprint so the next minute re-runs it) costs 0 reads/second today. In the last 7 days it fired 0 times. In 30 days it fired 187 times, all on one card at the Test Property, 2026-09-07 to 2026-09-09, and never since. Its peak cost was about 0.3 reads/second, against a floor of about 665. No fix is warranted.
Mechanism
The log line "a heal failed — fingerprint rolled back so the next tick retries this card" is at src/lib/domain/pms/writers/guest-card.ts:3680 on main. It fires only when a heal throws or returns failed. A refused repair returns ok and keeps its fingerprint, so it is not retried every minute.
Production counts
| Window | Records scanned | Rollback lines | Control |
|---|---|---|---|
| 7 days | 9,146,837 (none skipped) | 0 | The per-property summary line matched 40,920 in the same query, so the search ran |
| 30 days | 27,505,339 (~9% skipped) | 187 | One test card, Sept 7–9 only |
Query: CloudWatch Logs Insights on /aws/lambda/propflow-appfolio-sync-prod, filter /fingerprint rolled back/.
Other per-minute repeats found along the way
- Two properties re-save the same 2–4 rows every minute (~8.1k saves/day, ~1.8 reads/s). Small cost, but it also stops those buildings from ever counting as "nothing changed".
- About 29 cards per minute fleet-wide count as unchanged but still run their repairs (~9 reads/s, ~1.4% of the floor).
- The rental-applications job logs "Known-row match refused" ~5.8 times a minute and a failed applicant lookup ~2.6 times a minute. These are leads for that part of the work.