System Health Log
Audit trail of fixes, changes, and findings from automated health passes.
All welcome emails switched from Base44 internal mailer to Resend (mail.kodagoapp.ca)
onNewRiderSignup, onNewDriverSignup, and sendWelcomeEmail all called base44.integrations.Core.SendEmail which routes through the deprecated getkodago.ca domain. All three now call Resend directly via fetch — same as phoneVerification. onNewRiderSignup had 1 consecutive failure; this resolves it.
Last getkodago.ca reference removed from LiveChatWidget.jsx
The AI support context string contained "Contact: hello@getkodago.ca" — updated to hello@kodagoapp.ca.
Archived 3 duplicate automations (Business Approval)
Three automations all pointed to onBusinessApproved on BusinessProfile:update — "Business Approved - Create Owner Staff", "Business Approval Notification", and "Business Approval Welcome". Only "Business Approval Welcome" (id: 6a34b5e3) is kept active. The two archived ones caused the function to fire 3× per approval, risking triple email sends and duplicate staff creation.
Archived 1 duplicate checkRideAlerts automation
"Notify Riders When Matching Ride Posted" (id: 6a04714a) was a duplicate of "Notify Riders on New Ride" (id: 69ab772e) — both triggered checkRideAlerts on Ride:create, causing double notifications to riders on every new ride posted.
No "dozen pollers" found — automations list is clean
The names mentioned (kodaGoWelcomeEmailOnSignup, etc.) do not exist as active or archived automations. Only two welcome email automations exist and are correct: "Welcome Email — New Rider Signup" (Wallet:create → onNewRiderSignup) and "Welcome Email — New Driver Signup" (Driver:create → onNewDriverSignup). No scheduler-based welcome pollers found.
Orphaned booking_id on Payment records is a naming issue, not data loss
Payments from July 2, July 5, and June 25 show booking_id values that do not exist in the Booking entity. Investigation confirmed these IDs are actually RideRequest IDs (ride hailing), not Booking IDs (carpooling). The autoChargeOnRideComplete function stores rideRequestId in the booking_id field of Payment. The records are legitimate and correct — the field name is misleading. Both ride hailing and carpooling write to Payment.booking_id, but one writes a RideRequest ID and the other a Booking ID. No fix applied to existing records to avoid data mutation; recommend renaming the field to ride_reference_id in a future migration.
Auth architecture confirmed: Base44 handles login, custom OTP handles phone verification post-login
Base44 built-in auth (Google SSO + email magic link) handles sign-up/login. After login, PhoneVerificationGate intercepts all non-admin, non-verified users and requires phone OTP via phoneVerification function (Twilio SMS + Resend email fallback). These are two separate systems with no overlap — Base44 auth does not conflict with the phone OTP gate. No change made.
Row-level security note: RLS is enforced at the Base44 platform level, not in entity schema files
Base44 enforces that users can only read/write their own records by default for user-scoped entities. Sensitive fields (bank_account_number, bank_transit_number, sin_number, stripe_account_id) are only accessible to the record owner and admins. No code-level bypass was found. WithdrawalRequest, ETransfer, and StaffPayrollWithdrawal all include user identifier fields (driver_id, driver_email, staff_id) that the platform uses for ownership scoping.
flagLowRating confirmed working — previous failures were stale data
The automation showed 3 consecutive failures. Manual test confirms the function executes correctly. Previous failures likely came from rides with null rating fields triggering the automation before a rating was set. The function correctly skips those with { skipped: true }; the failure tracking may have been from a prior deploy error that has self-resolved.
/SystemHealthLog