Skip to main content
Owner: Backend Engineering and QA Last reviewed: 2026-09-23 Next review: 2026-12-23 Use this checklist with the lifecycle guide to verify backend behavior and the integrated frontend journey.

Automated regression checks

From the server repository, use Node 24 and pnpm 9.15.4:
The last recorded implementation verification passed all 54 focused tests and the full TypeScript check. The older cart/order suites had the same 41 failures before and after the rebooking change; they are not a passing full-suite result. Rerun the checks for the revision being released. The focused tests use mocked external dependencies. They cover permissions, prompt payloads, scheduling rules, free/paid paths, sequential duplicate payment processing, approval, attendance reset, release scheduling, cart/direct repeat purchases, course ownership protection, and separation of booking/enrollment/ledger records.

Live test prerequisites

  • Select a non-production Infisical environment with secrets path /server and confirm disposable student/consultant accounts, test notification recipients, and sandbox payment integrations. Do not record secret values in iHub.
  • Deploy the relevant backend revision and run the required workers, database, queue, and notification integrations.
  • Prepare a missed session with rescheduling enabled and an available replacement time, plus consultations covering free, paid, one-off, and recurring purchases.
  • Record the tested revision/environment and evidence. Live checks below remain unverified until their actual results are recorded.

Consultant prompt and rescheduling acceptance

  • Owning consultant prompts a missed session; receive HTTP 201, actual email, and in-app notification with correct IDs and SESSION_RESCHEDULE_REQUESTED.
  • Verify prompting leaves persisted session dates, status, attendance, and payment unchanged.
  • Reject unauthenticated/unrelated callers, missing sessions, invalid UUIDs, non-missed sessions, cancelled bookings, disabled rescheduling, exhausted limits, and pending reschedule payments. Surface notification-trigger failures.
  • Student opens the notification, selects a future available time, and submits rescheduling. Verify replacement-time notice for missed sessions, cooldowns, and rejection of past/unavailable times and unauthorized callers.
  • Free rescheduling persists rescheduled and replacement dates, clears attendance, and replaces reminder/status/finalization jobs.
  • Paid rescheduling retains old dates until sandbox payment is confirmed by the backend. Replay the payment callback and inspect for duplicate effects.
  • Owning consultant/admin approval produces scheduled and the student notification.
  • Both parties join the replacement session. Completion and worker execution update attendance/status and schedule the original ledger entry’s release after the hold. Inspect actual release separately; scheduling release is not settlement.

Rebooking acceptance

  • For a previously purchased consultation, enrollment check permits purchase through canPurchase, including when isEnrolled remains true. Verify all frontend booking/checkout gates use canPurchase.
  • Purchase the same consultation again at a new time through both direct and cart checkout, including an existing active booking and a completed booking.
  • Verify current price and new payment reference; after payment processing, inspect separate order, enrollment, booking, sessions, and ledger entries.
  • Verify the earlier booking, session dates, enrollment links, and payments are unchanged, and each new session links to its own order’s enrollment.
  • Cover a zero-total purchase and a recurring purchase with a fresh session set.
  • Recheck a cart slot taken after insertion; checkout must reject it. Retain unavailable-slot, inactive-product, self-booking, duplicate-cart-entry, and duplicate-course-purchase restrictions.
  • Replay fulfillment for the same order item; no duplicate booking or credit may be created. A second purchase uses a different order item.

Record the result

For each run, record revision, environment, date, test-account identifiers, pass/fail per case, and sanitized evidence or bug references. Keep tokens, secrets, and customer personal information out of screenshots and logs attached to the result.