איך עושים? 🙂‍↔️😕

[שיחה ממתינה]

אני נתקל בבאג די מוזר בשלוחה שמשלבת נתונים משרת חיצוני ומעבירה אותם הלאה לשלוחה אחרת, ואשמח לעזרת המומחים כאן.
תיאור המקרה:
הגדרתי שלוחה ראשית (נניח 1) כ-type=api. היא פונה לשרת שלי, מקבלת חזרה קובץ הגדרות זמני ומבצעת read למשתמש.
בקובץ ה-ext.ini של השלוחה מוגדר:

type=api
api_link=https://myserver.com
api_add_id_list_message=yes
api_timeout=5

השרת מחזיר בהצלחה את הפרמטרים ויוצר משתנה גלובלי (לדוגמה [Read_Variable]). מיד לאחר מכן, המערכת אמורה להעביר את המחייג לשלוחה 2 (שהיא שלוחת תפריט רגילה type=menu) לצורך ניתוב מבוסס משתנה באמצעות go_to_folder.
הבעיה:
בכ-15% מהשיחות (בעיקר בזמני עומס), נראה שיש Race Condition (תחרות ריצה) במערכת. המשתנה [Read_Variable] מגיע לשלוחה 2 כשהוא ריק או שהוא מכיל את הערך של המחייג הקודם בתור (כאילו ה-Session לא נסגר בזמן והתבצעה דריסת זיכרון).
במערכת הלוגים של השרת שלי (API Logs) אני רואה סטטוס 200 OK מלא, והנתונים נשלחים תוך פחות מ-200 מילישניות, כך שזה לא קשור ל-Timeout.
האם מישהו נתקל בתופעה הזו?
האם יש דרך לאלץ Flush או Clear למאגר המשתנים הדינמיים של ה-IVR לפני המעבר לשלוחה הבאה, או שחובה לעבוד כאן עם Bridge ייעודי כדי לשמור על ה-Token של השיחה הנוכחית?
תודה מראש לכל העוזרים!

[שלוחה-404]

@שיחה-ממתינה אני לא מכיר את כל המוסגים שכתבת אבל הבעיה ידועה מבחינת ימות הם לא יודעים לאיזה משתמש הגדרת את ההגדרות ואם שתיים חייגו ביחד אז זה יכול לדרוס את הקובץ וכן אם חייגו בהפרש קטן אז המחייג השני ישתמש בהגדרות של הראשון
הקוד שלך מוגדר נכון לקבל קלט של כל משתמש ולזכור מה כל אחד הקיש ? אולי הקוד שלך בזמני עומס מערבב בין משתמשים ?

[שיחה ממתינה]

תודה על כיוון החשיבה, אבל שללתי לחלוטין ערבוב Threads בשרת שלי. השרת רץ בארכיטקטורת Stateless מלאה בתוך Node.js (סביבת single-threaded עם Event Loop אסינכרוני), וכל בקשה נכנסת מקבלת Context מבודד לחלוטין בזיכרון (Scoped Instance). אין שום משתנה גלובלי משותף שיכול לגרום ל-Race Condition בצד השרת.
יתרה מכך, הלוגים מראים שה-UUID של השיחה (אני משתמש בפרמטר ApiCallId שנשלח מימות המשיח) מוצמד בצורה סטרקטורלית (Structured Logging) לכל תגובה שיוצאת מהשרת. הנתונים נשלחים חזרה עם ה-Token הנכון של השיחה הספציפית.
החשד שלי הוא שבגלל ששלוחת ה-API מחזירה פקודות דינמיות (כמו read או go_to_folder), ה-Parser של ימות המשיח בצד ה-Client (המרכזייה עצמה) לא מבצע הקצאת זיכרון דינמית נפרדת לכל ApiCallId ברמת ה-Scope של ה-IVR, אלא משתמש ב-Buffer משותף פר שלוחה.
אם שני מחייגים פונים לשרת באותו מילי-שנייה:

1. שרת ה-API מחזיר שני אובייקטים נפרדים ותקינים לחלוטין.
2. ימות המשיח מקבלת את שניהם, אבל ה-VXML Interpreter של המרכזייה דורס את המשתנה [Read_Variable] של מחייג א' עם הערך של מחייג ב', עוד לפני שהסשן של מחייג א' הספיק לבצע את ה-Evaluation של ה-go_to_folder.
   בגלל שאין לי גישה ל-Low-level Engine של ימות המשיח, אני שוקל לעקוף את המגבלה הזו:
   במקום להחזיר פקודות ישירות ב-Response של ה-API, אני אעביר את המערכת למוד אסינכרוני (Webhook-based). ה-API רק ירשום את השיחה ב-Redis DB שלי ויחזיר מיד לשלוחה פקודת המתנה (play_file), ובמקביל שירות רקע (Worker) יבצע פולטריגר ישיר באמצעות API חיצוני (כמו UpdateExtension) כדי להזריק את הערך ישירות לתוך קובץ ה-ext.ini הזמני של אותה שיחה באופן ממוקד.
   מישהו פה ניסה לעבוד בטופולוגיה כזו מול ה-API של ימות כדי לפתור בעיות Memory Leak או דריסת Buffers בזמני עומס?

[1668]

@שיחה-ממתינה אתה AI או איזה ספאם בוט

[שיחה ממתינה]

@1668 ???
יש לך תשובה עניינית?

[פלפל שחור]

@שיחה-ממתינה

זה בעיה סופר מוכרת לכל מי שמפתח קוד מול ימות המשיח. כשבונים שלוחת API ומנסים לשמור נתונים במשתנים הגלובליים של המערכת (כמו אלו שמתקבלים מהקשות בתוך שלוחת read), בזמני עומס המערכת לפעמים "מתבלבלת" ומערבבת בין המשתמשים כי ה-Session לא מופרד כמו שצריך בתוך ה-IVR.
הפתרון לזה הוא הכי בסיסי שיש ולא צריך שום בוטים:
במקום לתת לימות המשיח לשמור את המשתנים, פשוט תשתמש ב-ApiCallId הייחודי שימות שולחת לך לשרת בכל פנייה. תשמור את כל מה שהמשתמש מקיש אצלך בבסיס הנתונים (מצידי בקובץ טקסט פשוט או ב-MySQL) לפי ה-ID של השיחה.
כשאתה מעביר אותו שלוחה, אל תשתמש בערכים מקומיים של המרכזייה, אלא תמשוך את הנתון מהשרת שלך מחדש בכל פעם לפי מספר השיחה. ככה עבדתי במערכות של עשרות אלפי דקות, ואין שום סיכוי בעולם ששיחות יתערבבו, גם אם 200 איש מקישים באותה מילי-שנייה בדיוק.
פותח האשכול – ניסית לעבוד ככה, או שאתה נעול על להחזיק את המשתנים בתוך המרכזייה עצמה?

[1668]

@שיחה-ממתינה כתב:

@1668 ???
יש לך תשובה עניינית?

אני לא מבין AI

Spoiler

מה כתבת שם שעשו לך דיסליק

[רק תורה]

@1668 צודק לחלוטין את נשמעת בוט..

[שלוחה-404]

@שיחה-ממתינה למה שלא תחזיר בתשובה לשרת מה לבצע ? למה להגדיר בשלוחה ?