News Feed

batra-rudrakshgmail-com posted an update 5 months ago

5 months ago

Offer

0:25

0 Comments

batra-rudrakshgmail-com posted an update 5 months ago

5 months ago

File + poll

wrghrh

dfswghefgh

0%

sfghbfbn

0%

This is already an option

Options

Copy Download Link

# Pause Subscription — IST/UTC Timezone Bug Fix

**Date:** 2026-05-29  
**Affected Modules:** `orderGeneration.service.ts`, `customerSubscription.service.ts`, `getUpcomingDeliveryDate.utils.ts`, `orderGeneration.utils.ts`  
**Severity:** Critical (Production)  
**Reported By:** Production team

---

## 1. Business Context — How Pause Subscription Works

### Subscription Model
A customer subscribes to a meal plan (e.g., a 5-day lunch plan). The system automatically generates meal box orders for each working day (Monday–Saturday) within the subscription period. Sundays are excluded because Gutvana kitchens are closed.

### Pause Flow (Customer-Initiated)
1. A customer can **pause** their subscription for a future date or range of dates.
2. Pause always applies to **future dates only** — never for today or past dates.
3. When a pause is applied:
   - All auto-generated orders for the paused dates are **cancelled**.
   - No refund is issued for paused days.
   - The subscription's **end date is extended** by the number of paused working days (Sundays excluded), so the customer receives the full set of deliveries they paid for.
4. Only **one pause** is allowed per subscription.
5. Maximum pause duration is **7 working days** (as validated by the frontend).

> **Example:** Subscription ends June 5. Customer pauses for 1 working day (May 30).  
> System cancels the May 30 order and extends the subscription to **June 6** (skipping any Sunday that might fall in between).

### Unpause / Admin Override
- Only **admins** can cancel or modify a pause.
- If a pause is cancelled after some days have already passed:
  - Remaining days (from tomorrow onwards) have their cancelled orders **restored to pending**.
  - The subscription end date is **shrunk back** by the recovered days.
  - Days that have already passed while paused remain cancelled (no refund — but extension days for those past paused days remain to compensate).
- This ensures customers are never short-changed on meal deliveries they paid for.

---

## 2. Production Issues Reported

### Issue 1 — CUS000034
> **User paused for May 30, but the order for May 29 (Lunch) got cancelled.**

The pause was requested for May 30, but the wrong day (May 29) was cancelled in the database.

### Issue 2 — CUS000045
> **Pause applied for May 28–29, but two orders for May 28 got created and only one was cancelled.**

The system ended up with a duplicate order for May 28 — one cancelled and one active — even though no duplicate should ever exist for the same subscription, same date, and same slot.

---

## 3. Root Cause — The IST/UTC Timezone Shift Bug

### Background
The server runs in **IST (Indian Standard Time = UTC+5:30)**. When JavaScript's `Date` object is created and `setHours(0, 0, 0, 0)` is applied to set it to "midnight local time", the underlying UTC timestamp becomes **18:30:00 of the previous day**.

```
Local (IST):  2026-05-30 00:00:00  ← what we intend
UTC:          2026-05-29 18:30:00  ← what toISOString() sees
```

### Buggy Pattern
The codebase was converting dates to string format using:

```typescript
// BUG: Uses UTC internally — returns the previous day for IST midnight dates
date.toISOString().slice(0, 10)
date.toISOString().split('T')[0]
```

### How It Broke Issue 1
- Customer requested pause for **May 30** (local time).
- System stored `startOfDay(pauseStart)` as `2026-05-30 00:00:00 IST`.
- When looking up orders to cancel, the query used:
  ```
  pauseStart.toISOString().slice(0, 10)  →  "2026-05-29"  ← WRONG DATE
  ```
- The system cancelled orders for **May 29** instead of May 30.

### How It Broke Issue 2
- Customer requested pause for **May 28–29** (local time).
- Existing May 28 order was cancelled correctly (via DB lookup with correct date stored).
- However, when `OrderGenerationService` ran to generate upcoming orders, it used `toISOString()` to check if a scheduled date falls within the pause window:
  ```
  isWithinPauseWindow(date, pauseStart, pauseEnd)
    → toDateOnly(date)  →  "2026-05-27"  ← OFF BY ONE
  ```
- Because the schedule date `"2026-05-28"` was being serialized as `"2026-05-27"`, it **did not match** the pause window `"2026-05-28"` to `"2026-05-29"`.
- The generator found no active (non-cancelled) order for May 28 (it had been cancelled) and created a **new duplicate order**, resulting in two orders for May 28 — one cancelled, one active.

---

## 4. Fix Applied

### The Safe Pattern
Replace all `toISOString()` date-to-string conversions with a local-time-aware formatter:

```typescript
// FIXED: Uses local time components — always returns the correct local date
function formatDateYYYYMMDD(date: Date): string {
  const d = new Date(date);
  const year  = d.getFullYear();
  const month = String(d.getMonth() + 1).padStart(2, '0');
  const day   = String(d.getDate()).padStart(2, '0');
  return `${year}-${month}-${day}`;
}
```

`getFullYear()`, `getMonth()`, and `getDate()` all operate in **local time** — they return the exact calendar date as seen by IST users.

---

### Files Modified

#### `src/services/customerSubscription.service.ts`

| Location | Change |
|---|---|
| `getNonSundayDates()` | Replaced `d.toISOString().slice(0, 10)` → `formatDateYYYYMMDD(d)` |
| `initiateSubscription()` | Replaced `toISOString().split("T")[0]` for start/end dates → `formatDateYYYYMMDD()` |
| `pauseSubscription()` — error message | Replaced `minAllowedStart.toISOString().slice(0, 10)` → `formatDateYYYYMMDD(minAllowedStart)` |
| `pauseSubscription()` — skipped orders query | Replaced `pauseStart/End.toISOString().slice(0, 10)` → `formatDateYYYYMMDD()` |
| `cancelSubscription()` — refund queries | Replaced `actualRefundStartDate.toISOString().slice(0, 10)` → `formatDateYYYYMMDD()` |
| `adminUnpauseSubscription()` — resume_from | Replaced `resumeFrom.toISOString().slice(0, 10)` → `formatDateYYYYMMDD(resumeFrom)` |
| Upgrade flow — `transition_date` | Replaced `transitionDate.toISOString().split("T")[0]` → `formatDateYYYYMMDD(transitionDate)` |

---

#### `src/services/orderGeneration.service.ts`

| Location | Change |
|---|---|
| `toDateOnly()` (private helper) | Replaced `date.toISOString().slice(0, 10)` → `formatDateKey(date)` |
| `isWithinPauseWindow()` | Now uses fixed `toDateOnly()` — correctly identifies pause window dates |
| `getUserTodayOrderDetails()` | Replaced `new Date().toISOString().split('T')[0]` → `formatDateKey(new Date())` |
| `getTodayTrackingSummary()` | Same replacement |
| `getUserPastOrders()` | Same replacement |
| Debug log statements | Replaced `toISOString()` in logs → `formatDateKey()` |

> `formatDateKey()` was already a local-time-safe function in this file — it simply needed to be used consistently everywhere.

---

#### `src/utils/getUpcomingDeliveryDate.utils.ts`

| Location | Change |
|---|---|
| `toDateOnly()` | Replaced `date.toISOString().slice(0, 10)` → local component extraction |

---

#### `src/utils/orderGeneration.utils.ts`

| Location | Change |
|---|---|
| `formatDateToISO()` | Replaced `date.toISOString().split('T')[0]` → local component extraction |

---

## 5. What Was NOT Changed

- **`date.getDay() === 0` (Sunday check):** This uses local time — it was always correct. Not changed.
- **`startOfDay()` logic:** Uses `setHours(0, 0, 0, 0)` which sets local midnight — always correct. Not changed.
- **`countNonSundayDays()` and `extendByNonSundayDays()`:** These operate via `getDay()` in local time — always correct. Not changed.
- **`calculateGenerationWindow()`:** Uses local midnight math via `setHours(0, 0, 0, 0)` — not affected.
- **Database `DATEONLY` columns:** Sequelize stores `DATEONLY` fields as `YYYY-MM-DD` strings, which match our local-timezone-formatted strings exactly.

---

## 6. Why Only the String Serialization Was the Problem

In this codebase, `Date` objects are manipulated using local-time methods (`setHours`, `setDate`, `getDay`) which are all correct. The bug was **exclusively** introduced at the boundary where a `Date` object was converted to a `YYYY-MM-DD` string for:

- Passing to Sequelize `WHERE` clauses (`delivery_date: { [Op.between]: [...] }`)
- Comparing against pause window date strings

The IST offset of +5:30 meant that any date set to local midnight would become 18:30 UTC on the **prior day**, causing a consistent 1-day offset in all string-based comparisons against the database.

---

## 7. Testing Checklist

After deploying this fix, verify the following scenarios in staging:

- [ ] Pause for a specific date → only orders for **that exact date** are cancelled
- [ ] Pause for a date range → orders for **all dates in range** are cancelled (excluding Sundays)
- [ ] Subscription end date is extended by **exactly the number of paused working days**
- [ ] Extended end date is **never a Sunday**
- [ ] Order generation cron does **not** create orders for paused dates
- [ ] Order generation cron does **not** create duplicate orders
- [ ] Admin unpause (before pause starts) → all cancelled orders restored, end date reverted
- [ ] Admin unpause (mid-pause) → only remaining days restored, past paused days unchanged
- [ ] Today's order details API returns **correct date's orders** for IST users
- [ ] Past orders API correctly excludes today's orders for IST users

---

## 8. References

- Production incident: CUS000034 (May 29 order incorrectly cancelled during May 30 pause)
- Production incident: CUS000045 (Duplicate order for May 28 during May 28–29 pause)
- JavaScript `Date.toISOString()` MDN: always returns UTC representation
- JavaScript `Date.getDate()` MDN: returns day-of-month in **local** time

---

# Bug Fix #2 — Admin Subscription Search by Subscription ID

**Date:** 2026-06-02  
**Affected Module:** `src/services/customerSubscription.service.ts` → `getAllSubscriptionsAdmin()`  
**Severity:** Medium (Admin UX / Operational)  
**Reported By:** Internal admin team...

Expand

This file was truncated for preview. Please download to view the full file.

0 Comments