Skip to main content
All updates
Bug fixBookingsCheck InBilling·Fri Sep 04·

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.
Next update

Correct past class rosters safely

Venue teams and assigned professionals can correct eligible past attendance through a protected, silent workflow with an immutable reason.