# Analysis: Why R1 (PendingColabReminder1) was NOT scheduled for colab_id 206

**Analysis only. No code changes.**

---

## Context (from logs)

- **colab_id:** 206
- **11:04:15** → state = PENDING_COMPANY  
  → HistoryNotifier triggered  
  → `sendNewColabCompanyNotification` ran  
  ❌ No "Email scheduled"  
  ❌ No "sendNotificationAt"
- **12:30** → colab auto-cancelled

---

## Step 1 — What `handlePendingCompanyState` does

**File:** `app/Traits/HandlesHistoryTransitions.php` (lines 124–191)

1. **Always runs (no gating):**
   - `sendAcceptedColabCompanyEmail($colab)`
   - `sendNewColabCompanyNotification($colab)`  
   → This matches the logs: notification was sent, no scheduling yet.

2. **Reminder scheduling (R1/R2) only runs inside:**
   - `if (in_array($colab->collabable_type, CollabableConstants::DATABLE_COLLABABLE_TYPES)) { ... }`  
   So only for **datable** types (Activity, Lodging, Restaurant, Delivery). Brand uses a different branch (`scheduleBrandReminders`).

3. **Inside the datable block, scheduling depends on:**
   - `$ts = $colab->getDate();` then `if (!$ts) return;`
   - `$eventDeadline = $ts->copy()->subHours(2);`
   - `$maxPendingDeadline = $t0->copy()->addHours(24);`
   - `$cancelAt = min(eventDeadline, maxPendingDeadline)` (conceptually)
   - `$leadRealMinutes = $t0->diffInMinutes($cancelAt, false);`
   - Then **three early exits** that prevent any R1/R2:
     - `if ($leadRealMinutes <= 0) return;`
     - **`if ($leadRealMinutes <= 4 * 60) return;`**  ← **This is the one that applied for colab 206**
     - (If 4h < margin ≤ 12h: one reminder at midpoint; if margin > 12h: R1 at t0+6h, R2 at cancelAt−4h.)

So **R1 is only scheduled when** `leadRealMinutes > 4 * 60` (i.e. more than 4 hours until `cancelAt`).

---

## Step 2 — Gating conditions (in order)

| # | Condition | Location | Effect if false |
|---|-----------|----------|------------------|
| 1 | `in_array($colab->collabable_type, CollabableConstants::DATABLE_COLLABABLE_TYPES)` | Line 129 | Entire reminder block skipped (Brand goes to `scheduleBrandReminders` instead). |
| 2 | `$ts = $colab->getDate(); if (!$ts) return;` | Lines 132–135 | No date → exit; no reminders. |
| 3 | `$leadRealMinutes = $t0->diffInMinutes($cancelAt, false); if ($leadRealMinutes <= 0) return;` | Lines 144–147 | Cancel time already in the past → exit. |
| 4 | **`if ($leadRealMinutes <= 4 * 60) return;`** | Lines 149–151 | **Less than or equal to 4 hours until cancel → exit; no R1/R2.** |

There are **no** conditions on `$user`, `$colab->offer`, or `$colab->is_datable` in `handlePendingCompanyState`; the only gates are the ones above.

---

## Step 3 — What happened for colab 206

- **State:** PENDING_COMPANY at 11:04:15 → `sendNewColabCompanyNotification` ran, so `handlePendingCompanyState` ran.
- **user_id 11 (company user):** Not used for scheduling in this method; no gate on `$user` here.
- **Auto-cancel at 12:30** implies the cancel deadline `cancelAt` was at or before 12:30.

So at **11:04:15**:

- `t0` = 11:04:15  
- `cancelAt` = min(event − 2h, t0 + 24h). With event same day (e.g. 14:00), eventDeadline = 12:00; if that’s before t0+24h, then **cancelAt ≈ 12:00** (or very close; in any case before 12:30 when it was cancelled).
- **leadRealMinutes** = minutes from 11:04 to cancelAt ≈ **56 minutes** (if cancelAt was 12:00).

So:

- `leadRealMinutes` (≈ 56) **≤ 4 * 60** (240)  
- The code hits **`if ($leadRealMinutes <= 4 * 60) return;`** and exits **before** any call to:
  - `schedulePendingColabReminder1CompanyEmail`
  - `schedulePendingColabReminder1CompanyNotification`
  - (and same for R2).

So **no** “Email scheduled” and no “sendNotificationAt” for R1/R2.

---

## Step 4 — Conclusion

- **Why R1 was not scheduled**  
  R1 (and R2) are only scheduled when there are **more than 4 hours** until the pending-company cancel deadline. For colab 206, at the time it entered PENDING_COMPANY (11:04:15), there were only about **1.5 hours** until that deadline (cancel around 12:00–12:30), so `leadRealMinutes <= 4 * 60` and the method returns without scheduling any reminder.

- **Which condition blocked it**  
  **`if ($leadRealMinutes <= 4 * 60) return;`** in `HandlesHistoryTransitions::handlePendingCompanyState` (lines 149–151). So the “≤ 4 hours until cancel” gate is the one that prevented scheduling.

- **Expected behavior or bug?**  
  **Expected behavior.** The logic is intentional: if the company has 4 hours or less to accept, the system does not schedule the “pending company” reminders (R1/R2). That avoids scheduling reminders that would be cancelled almost immediately when the colab auto-cancels. So for colab 206, the event (or the 24h cap) was so close that the cancel deadline was already within 4 hours of entering PENDING_COMPANY; hence no reminder scheduling.

---

## Summary

| Question | Answer |
|----------|--------|
| Why was R1 not scheduled? | Time until cancel deadline was ≤ 4 hours, so the code returns without scheduling R1/R2. |
| Which condition blocked it? | `if ($leadRealMinutes <= 4 * 60) return;` in `handlePendingCompanyState`. |
| Expected or bug? | **Expected.** Reminders are not scheduled when there are 4 hours or less until the cancel deadline. |