News Feed

batra-rudrakshgmail-com posted an update

3 months ago
File + poll

wrghrh

dfswghefgh

0%

sfghbfbn

0%

Submit option

This is already an option

0 votes Poll Closed
Documents

Folder Title Following special characters are not supported: \ / ? % * : | " < >

Privacy

Cancel Create

Create new folder Cancel Move
BUG_FIXES_README.txt 25 KB Text File - Click to view

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

wrghrh

Quick Links

Legal

Contact

support@fertiliga.com

+91 76515 21351

3rd Floor, Liberty Tower, Plot No. K-10, Behind Reliable Plaza, Kalwa Industrial Estate, Airoli, Navi Mumbai, Thane 400708, India