Automatic no-shows now use the protected history path
The nightly class close-out now continues to mark eligible unattended bookings after a class becomes a past record. It uses the same venue-configured no-show consequence, fee, audit, webhook and notification behavior as before, through the database's protected lifecycle path.
The nightly class close-out now continues to mark eligible unattended bookings after a class becomes a past record. It uses the same venue-configured no-show consequence, fee, audit, webhook and notification behavior as before, through the database's protected lifecycle path. The job also reports a failed run when a class or booking cannot be updated. This prevents an automation problem from appearing healthy while bookings stay confirmed. One failed record does not cause the job to repeat a successful fee or notification for another member. Existing missed no-shows are not charged automatically by this repair. They remain available for an authorized, reviewed historical correction. The database records the instant the protected executor is installed. Both automatic workers use that as a hard eligibility floor, and the booking-write guard independently enforces the same floor. Therefore neither the first healthy run nor an older worker running between the migration and application deployment can convert bookings left behind by the broken job into fees or notifications. The fee floor does not suppress class lifecycle accounting: an older class may still be completed and its instructor compensation recorded, while its pre-activation bookings remain outside automatic no-show processing. Automatic candidates must also remain member-owned. Provider inventory, guest-only rows, and retained identity-severed evidence are excluded by the worker and independently rejected by the database guard so their specialist lifecycle cannot be mistaken for an ordinary member fee. The worker now reads every eligible class and booking page explicitly instead of relying on the database API's single-response row limit. A truncated sweep can no longer appear successful, and the compatibility worker uses the same activation-bounded time window. The overnight sweep is exactly the preceding calendar day in the platform IANA timezone, including DST days. Daytime recovery keeps a two-hour late-check-in grace period and can retry only the prior 35 hours after activation. A booking that staff check in or cancel while the worker is running is counted as safely skipped, not retried as a no-show fee. Business-app check-ins now also carry the staff member's authenticated after-cutoff permission into the attendance engine. Previously, a bearer-only app request could incorrectly fall back to a missing browser cookie and report that check-in was closed even when the staff member had the explicit grant. Single, bulk, and course-session attendance use the same corrected rule.
Correct past class rosters safely
Venue teams and assigned professionals can correct eligible past attendance through a protected, silent workflow with an immutable reason.