🧠 מוניטור

סיכום: MyOne היא חברת תכשיטים שמנהלת הזמנות דרך Shopify. בנינו להם מערכת חזקה שמחברת בין הלקוחות (שמילאו טפסים עם בקשות חריטה, תמונות וברכות), הספקיות בסין (שמקבלות את הבקשות דרך פורטל), וחנות ה-Shopify. המערכת כוללת אוטומציות שמשלחות הודעות בוואטסאפ, טבלות ב-Airtable, צ'אט בזמן אמת, וממשק ספק. לאחרונה היה גל של תקלות: מוצרים לא מוכרים חסמו בקשות, חריטות נתקעו בתור, מספרי טלפון היו חסרים, תמונות לא הופיעו, והוואטסאפ היה לא יציב. עברנו על הכל, תיקנו את הבאגים, שחזרנו נתונים ישנים, ואימתנו שהמערכת עובדת קצה לקצה. כרגע: המעקב הישן של טפסים כבוי (כי הוא רץ לחינם כ-4 פעמים ביום לאחר שסיים את ההודעות שלו), והאוטומציות הגדולות (חריטה, תמונה, ברכה, שליחה) פועלות תקין. החלטות: 1. כבינו את משימת המעקב הישנה (myone-fill-followup) כי היא הגדירה לעצמה חלון זמן של יומיים בלבד ביולי ועדיין רצה בספטמבר. 2. הוספנו מוצרים חדשים (מתנות, אריזות) לטבלת המוצרים עם ערך ברירת מחדל של 4 חריטות, כי מוצרים לא מוכרים חסמו את כל השליחה. 3. תיקנו את באג הברכה שדרס תמונות (שדה לא נכון בטבלה). 4. הוספנו בוטל שנוקה 141 הודעות שנתקעו בתור בלילה וקבענו בוקר שמושך את כל מה שנתקע. 5. עברנו לוואטסאפ רשמי (MegaSend) כדי לשלוח מהר יותר וביציבות. 6. שחזרנו 71 חריטות שלקוחות מילאו בקנייה ולא נכנסו למערכת, ובנינו תרחיש שמשיכה חריטות מ-Shopify כל בוקר לבד. 7. סגרנו פרצת בטיחות: הספקיות לא יכולות עוד לראות הזמנות של ספקות אחרות ולא חשפנו להן פרטי לקוחות. דפוסים: ✅ צ'אט בזמן אמת עובד טוב: תמונות מופיעות, קבצים מצורפים בנוחות, הודעות מגיעות מהר. ✅ משלוח בוקר: כל פעם בבוקר האוטומציה משולחת הודעות שנתקעו. ✅ אימות: כל תקלה גדולה שתיקנו אנחנו טסטנו קצה לקצה עם מספר של סשה. ⚠️ בעיה עם מוצרים: כל מוצר חדש שלקוח קנה צריך להיות בטבלה, אחרת בקשה נתקעת בשקט. ⚠️ מידע חסר: אם הזמנה נכנסה בלי מספר טלפון היא לא יכלה לקבל וואטסאפ, צריך לחזור ל-Shopify ולמשוך. ⚠️ זמני שליחה: בלילה בקשות נתקעות בתור אם השעה לא בטווח 7-21, וחייב להיות בוטל בבוקר שמרוקן את התור. ⚠️ בדיקה הספקית: ביתא (ספקית בסין) לא רואה תוכן שלקוחות מילאו, לא בגלל המערכת שלנו אלא בגלל בעיה שלה / חסימת אינטרנט בסין. זה לא בעיה שלנו.

POST-PAYMENT RECOVERY, 08.10.2026. STEP 1 VERIFY SENDING RESUMED: scenario runs on 08.10 all status 1 (7609098 OK at 04:35,04:36,12:02,12:28,12:32; 7608761 OK at 12:45-12:46). Last subscription-caused failure was 2026-10-07T13:21. Confirmed fixed. STEP 2 SCOPE: pulled every DLQ item across the 5 affected scenarios and extracted the recordId from each stored bundle. 151 failed sends caused by the subscription error, window 2026-09-27T20:25 to 2026-10-07T17:19, but only 24 DISTINCT orders - the same orders were retried dozens of times by the 15-min Airtable cron. STEP 3 TRIAGE (resolved 22 of 24 via the Supabase edge function, scanning 195 pages since the Airtable MCP token lost base access): 4 already filled in by the customer (42724, 42699, 42674, 42658-photo), 7 already auto-recovered after payment was restored (42631, 42607, 42531, 42702, 42659, 42649, 42644), 12 still had messageSent=false and no content. STEP 4 SEND: fired each of the 12 at its own scenario webhook with {recordId}, 4s apart, at 15:59 Israel time (inside the 08:00-21:00 window). Hooks used: carving wh6erunn..., card lko823..., photo bvbfqj18... All 12 returned Accepted. STEP 5 PROOF (broadcast-verify: Accepted is a claim, not evidence): re-read each order through the edge function - all 12 now show messageSent=true with timestamps 12:59:53 through 13:00:42 on 08.10. 12/12 verified. DLQ counts unchanged at 57/41/32 so zero new failures; post-fire runs all status 1. SENT LIST: card 42599 42606 42632 42655 42658 42701 42734 42739, photo 42694 42722, carving 42700 42733. STEP 6 BONUS FIX: scenario 9585906 module 2 now has a guard filter (id exists AND id starts with rec) which stops the daily 05:05 webhook firing with an empty recordId - that was generating one failed execution and one error email to Yehonatan every single morning since 19.08. Verified the scenario still contains only airtable search + http, no sending module. OPEN: 2 records (recClaW9v9byW2W7j, recz3jiPSvvcgjDmc) could not be resolved to an order number; both are carving-confirmation receipts from 7609224, low impact, not re-fired. Airtable MCP token still lacks access to base appPQDFxoqx8FaoQU (403 on list_tables).

ROOT CAUSE FOUND for all 159 Make errors Yehonatan is getting emailed about. Single cause, not a code bug. Failing module in every case: app#megasend-cloud-8fceiv:sendTemplateMessage. Verbatim provider response: [403] {"detail":{"error":"subscription_payment_failed","message":"Your last subscription payment did not go through, so sending is paused. Update your payment method to start sending again.","action_required":"update_payment_method","upgrade_url":"/subscription/manage","grace_days":7}}. After grace expiry the error becomes [403] {"detail":"No active subscription found"}. TIMELINE: first payment_failed 2026-09-27T20:25. 7-day grace ran 27.09-04.10. From 04.10 hard stop - No active subscription found dominates. Daily failure counts escalate: 28.09=8, 04.10=17, 05.10=7, 06.10=78, 07.10=20. Latest failure 2026-10-07T13:21, still failing right now. AFFECTED SCENARIOS AND DLQ: 7608761 carving requests 57 (all 50 sampled = No active subscription, window 06.10-07.10), 7609151 missing photo 41 (25 no-subscription + 16 payment-failed, since 28.09), 7609098 greeting card 32 (25 + 7, since 28.09, status 2 on every single run), 7537584 manager callback 26 (16 + 10, since 27.09), 7609224 carving uploaded 3 (28.09). BUSINESS IMPACT: zero customer WhatsApp has gone out since roughly 04.10 - carving requests, photo requests, greeting card requests and manager callbacks all silently dead. Orders keep arriving and nobody is being contacted. NOT AFFECTED: scenario 9667632 daily Shopify carving pull is clean (DLQ 0) because it contains no sending module, so carving data is still being pulled correctly. FIX IS NOT TECHNICAL: Yehonatan must update the payment method in the MegaSend account at /subscription/manage. Sending resumes immediately once the subscription is active; the failed sends in the DLQ then need a deliberate catch-up decision. ALSO NOTED: Airtable MCP lost access to table tblreKJN88Ooi2BxO this session (422 could not find table) although the Supabase edge function still reads the base fine - worth re-checking the MCP token. NO PRODUCTION CHANGE MADE.