Skip to content

chore: Integrate confirmation booking audit#10

Open
tomerqodo wants to merge 2 commits into
cursor_full_base_chore_integrate_confirmation_booking_audit_pr10from
cursor_full_head_chore_integrate_confirmation_booking_audit_pr10
Open

chore: Integrate confirmation booking audit#10
tomerqodo wants to merge 2 commits into
cursor_full_base_chore_integrate_confirmation_booking_audit_pr10from
cursor_full_head_chore_integrate_confirmation_booking_audit_pr10

Conversation

@tomerqodo

@tomerqodo tomerqodo commented Jan 25, 2026

Copy link
Copy Markdown

Benchmark PR from agentic-review-benchmarks#10


Note

Integrates booking-audit into confirmation/rejection flows with explicit actor and actionSource propagation and bulk handling.

  • Add actor via makeUserActor and actionSource (API_V2, WEBAPP, WEBHOOK, MAGIC_LINK) to confirmHandler, API v2 services, and magic-link routes
  • Update handleConfirmation to fire booking accepted audit events (single/bulk) via BookingEventHandlerService; add equivalent rejection flow in confirm.handler
  • Introduce getAppActor and pass app actors to payment success path; refactor handlePaymentSuccess to new param object and include actor
  • Extend audit services: new/updated RejectedAuditActionService; producer interface/tasker supports queueBulkRejectedAudit
  • Add Prisma enum BookingAuditSource.MAGIC_LINK and migration; export makeUserActor in platform
  • Update Alby/BTCPay/HitPay/PayPal/Stripe webhooks to use new payment success API and provide appSlug
  • Expand tests: magic-link/verify-token routes, confirm handler, and audit integration

Written by Cursor Bugbot for commit 0626d90. Configure here.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

oldStatus: BookingStatus.ACCEPTED,
uid: booking.uid,
},
];

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong old status recorded for non-recurring booking acceptance

Medium Severity

When accepting a non-recurring booking, oldStatus is hardcoded to BookingStatus.ACCEPTED instead of using booking.status. This records the new status as both old and new in the audit log, defeating the purpose of tracking status changes. The booking parameter already contains the original status property which represents the state before the update.

Fix in Cursor Fix in Web

rejectedBookings = updatedRecurringBookings.map((recurringBooking) => ({
uid: recurringBooking.uid,
oldStatus: recurringBooking.status,
}));

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong old status recorded for recurring booking rejection

Medium Severity

For recurring booking rejection, rejectedBookings is populated from updatedRecurringBookings which is fetched AFTER the status update to REJECTED. This means oldStatus contains the new status (REJECTED) instead of the original status (PENDING). The existing unconfirmedRecurringBookings variable (fetched before the update) contains the correct pre-update status and should be used instead.

Fix in Cursor Fix in Web

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant