2026. október 4. · Vizsgálat és terv · Éles módosítás nélkül

Naptár → CRM: mi hibázott, mit érdemes javítani?

Két igazolt sikertelen futás ugyanahhoz a triggerhez. A pontos kiváltó ok és a kimaradt foglalások száma még nem igazolt. A külön értesítő kódjában viszont konkrét javítandó kockázatok látszanak.

1. Válaszlevél Sándornak

Állapot: piszkozat, nem lett elküldve. Tárgy: Re: Summary of failures for Google Apps Script: Lovasember - Naptár CRM Sync

Szia Sanyi! Megnéztem a hibaértesítést és a kapcsolódó CRM-rendszert. Az október 2-i hajnali futásnál a naptár és a CRM-tábla közötti szinkron megállt egy szerverhibával. Ugyanettől az automatizmustól augusztusban is érkezett ilyen értesítés, ezért érdemes a visszatérő hibát kivizsgálni. Ez önmagában még nem jelenti azt, hogy a foglalás eltűnt a naptárból. Azt kell ellenőrizni, hogy minden foglalás átkerült-e a táblába, és a későbbi futás pótolta-e az esetleges kimaradást. A levél alapján azt sem lehet biztosan kijelenteni, hogy kizárólag a Google oldalán volt a probléma. A CRM-táblát és a külön foglalási értesítő kódját elérem. Az értesítőnél találtam egy javítandó működést: sikertelen levélküldés után is továbbléphet az adott soron, ezért az értesítés később kimaradhat. Ez külön kérdés a most jelzett naptárszinkron-hibától. A következő lépés a hibás szinkron futási naplójának és kódjának ellenőrzése, majd a naptár és a CRM összevetése. A javításnál az esetleges kimaradások pótlását, a duplikációk elkerülését és a kézi jegyzetek megőrzését is ellenőrizni kell. Ehhez kérlek, a Google Apps Scriptben a „Lovasember - Naptár CRM Sync” projektet oszd meg szerkesztésre a matyas@clientsflow.hu címmel, és küldd el a projekt linkjét. Ha ez a megosztás nem elérhető, a projekt kódjának exportja és az október 2-i futás részletes hibanaplója is segít. Jelszót nem kell küldened. Üdv, Matyi

2. Ellenőrzött tények és nyitott kérdések

2 futásAug. 27. és okt. 2.

126 másodpercAz októberi hibás futás hossza

179 adatsorA nyers és a konzultációs fülön

A mostani hiba: október 2., 00:11:08–00:13:14 CEST, sync, időzített trigger. A Google értesítése október 3-án érkezett, a továbbított levél aznap 10:13:58-kor. A hiba dátuma és az értesítés dátuma különbözik.
Korábbi ismétlődés: augusztus 27., 02:41:08–02:43:08 CEST. Mindkét levél ugyanarra a triggerre mutat és azonos szerverhiba-szöveget tartalmaz. Ez két igazolt hiba, nem folyamatos leállás bizonyítéka.
Friss táblázat-ellenőrzés: az „Egyéni” és „Konzultációk” fül 179 adatsort ad vissza. A nyers fül 52 kitöltött eseményazonosítójában nincs ismétlődés. A lekért A:O tartományban nem látszott a vizsgált képlethibák egyike sem. A nyers fül utolsó sorában október 1-i dátum szerepel. Ezek a táblázat állapotát mutatják, nem igazolják a teljes naptárszinkront.
Hozzáférési határ: az ügynökségi API-fiókkal a CRM és két kapcsolódó Apps Script olvasható. A pontos „Naptár CRM Sync” projekt nem szerepel az elérhető projektek között. A célzott céges naptár lekérése 404-et adott, ami nem bizonyítja, hogy a naptár nem létezik. A háttérböngészős próbával sem sikerült a trigger részleteit beolvasni.

Még nem tudjuk: melyik kódsor vagy Google-szolgáltatás hibázott, mi történt az utána következő futásoknál, van-e kimaradt vagy részben feldolgozott foglalás, illetve működik-e az automatikus pótlás. A kétperces futás nem bizonyítja a teljes Apps Script futásidőkeret túllépését.

Konkrét kockázatok a külön értesítőben

Megállapítás	Lehetséges következmény	Javasolt javítás
A `checkNewBookings` a levélküldési hibák összegyűjtése után is az utolsó sorra állítja a vízjelet.	A sikertelen értesítés következő futáskor már nem kerül újra feldolgozásra.	Eseményenkénti állapot és újrapróbálható hibasor. Csak a sikeresen kezelt tételek jelölése késznek.
Nincs a párhuzamos feldolgozást kizáró futászár.	Két futás ugyanazt az új sort olvashatja, és duplán küldhet értesítést.	Futászár és tartós eseménykulcs. Levélküldés utáni bizonytalan állapotnál egyeztetés szükséges, mert a levél és az állapotmentés nem egyetlen tranzakció.
A feldolgozás sorszámra és hozzáfűzésre épít. A hiányzó vízjel automatikusan a jelenlegi utolsó sorra áll.	Sorok rendezése/törlése vagy állapotvesztés kimaradást, illetve téves feldolgozást okozhat.	Stabil eseményazonosító használata. Hiányzó állapotnál látható eltérés és ellenőrzött egyeztetés, ne csendes továbblépés.
A Stripe-figyelő legfeljebb 100 fizetést kér le lapozás nélkül. A függő fizetésből önmagában hiányzó foglalást állít, és rögzített hét napos lejáratot becsül.	Régebbi tételek kimaradhatnak. A riasztás bizonyíték nélkül állíthatja, hogy nincs foglalás.	Lapozás és fizetés–foglalás egyeztetés. „Ellenőrzendő függő fizetés” megfogalmazás, szolgáltatói lejárati adat, ha rendelkezésre áll. Nincs automatikus terhelés vagy törlés.

Ezek olvasott forráskódból igazolt működések, nem igazolt ügyfélveszteségek. A kapcsolódó scriptek triggerének jelenlegi telepítése nem lett ellenőrizve.

A CRM nézet további ellenőrizendő pontjai

A konzultációs nézet több oszlopa FILTER képlettel követi a nyers adatokat, míg a kézi jegyzetek és státuszok sorhoz kötöttek. Nyers sorok átrendezése elválaszthatja a kézi adatokat a személytől. A D2 és E2 cellában a mintavételkor nem a nyers adatokat követő FILTER képlet szerepelt. Ellenőrizni kell, hogy ez szándékos kézi felülírás-e. Az IFERROR üres eredménnyel elrejthet egy későbbi képlethibát, ezért a frissességet külön ellenőrzés igazolja.

3. Javítási terv, végrehajtási sorrendben

P0 · Azonosítás és mentés. A pontos szinkronprojekt linkje, tulajdonosa, kódja, beállításai és futási naplója szükséges. Az október 2-i hiba és az azt követő futások állapota legyen meg. Módosítás előtt szűk kód- és táblamentés, dokumentált visszaállítás. Az értesítő vagy a júniusi újraépítő script nem helyettesíti a hibás projektet.
P0 · Foglalások egyeztetése. A legutolsó igazolt teljes sikeres feldolgozástól a jelenig hasonlítsuk össze a naptáreseményeket és a nyers CRM-adatokat, lapozva, stabil eseménykulccsal. Külön lista: hiányzó, ismétlődő, átütemezett, lemondott és kézi bejegyzés. Az augusztusi eset utáni pótlást is ellenőrizni kell. A naptárbejegyzés és a fizetés külön bizonyíték.
P1 · A naplóval igazolt ok javítása. A hibázó műveletnél átmeneti hibára korlátozott újrapróbálás, növekvő várakozással. Jogosultság- vagy adatproblémát ne kezeljünk végtelen újrapróbálással. Kötegelt olvasás/írás és lapozás. Futásazonosító, lépés, darabszám és utolsó teljes siker naplózása személyes adatok nélkül.
P1 · Megszakítás és újrafutás kezelése. Futászár, eseménykulcs alapján frissítés vagy beszúrás, adatírás után mentett feldolgozási állapot. Ha a script inkrementális kurzort használ, az csak teljes siker után lépjen tovább. Időablakos feldolgozásnál átfedő visszaolvasás, a tényleges késésekhez igazítva. Többoldalas eredmény és részleges írás után az ismétlés ne hozzon létre duplikációt.
P1 · Értesítési hibák javítása. A hibás küldés maradjon újrapróbálható, a sikeresen küldött értesítést ne küldjük újra automatikusan. A bizonytalan kimenetel külön állapot és egyeztetés legyen. A vízjel átállítása vagy újrainicializálása ne fedjen el korábbi kimaradást.
P2 · A CRM kézi adatainak és nézeteinek megőrzése. Az eseményekhez kapcsolt stabil kulcs alapján őrizzük a jegyzeteket és státuszokat. Ellenőrzött sorváltoztatási teszt, fejléc/típus-ellenőrzés, szándékos kézi felülírások leltára, látható képlethiba és frissességi állapot. A Stripe-figyelő kockázatait külön változtatásként kezeljük.
P1 · Pótlás és éles ellenőrzés. A tesztek után a hiánylistából ellenőrzött pótlás. Korábbi foglalások értesítőinek tömeges újraküldése előtt külön lista szükséges. Végül legalább két egymást követő időzített futás és egy valós esemény–CRM egyezés, a mellékhatások visszaolvasásával.

Felelősség: Sándor biztosítja a pontos tulajdonosi projekt elérését. A technikai végrehajtó azonosítja az okot, elkészíti és teszteli a javítást, majd megőrzi a mentést és az eredményigazolást. Időigény a napló és a kód után becsülhető megbízhatóan.

4. Mikor tekinthető javítottnak?

Az ellenőrzött időszak minden releváns eseménye egyeztethető a megfelelő CRM-sorral. A szándékosan kihagyott események oka rögzített.
Ugyanaz a bemenet kétszeri feldolgozásával nincs új duplikáció vagy kézi adatfelülírás.
Átütemezés és lemondás helyesen frissül, többoldalas lekérés teljes.
Mesterséges olvasási/írási hiba és megszakítás után a következő futás pótol, nem veszít tételt és nem léptet tévesen kurzort.
Sikertelen értesítés később feldolgozható. Párhuzamos futás nem dolgozza fel egyszerre ugyanazt a tételt. Bizonytalan levélküldési állapot nincs sikerként feltüntetve.
A kézi jegyzetek és státuszok megmaradnak. Két friss időzített siker és esemény–CRM visszaellenőrzés igazolja az éles működést.

Mostani eredmény: vizsgálat, javítási terv és válaszlevél kész. Javítás, tesztfoglalás, fizetési művelet és ügyféllevél-küldés nem történt.

Források és bizonyítási határ

A csatolt képernyőképet két eredeti, API-n olvasott továbbított levél támasztja alá. Friss Google Drive, Sheets és Apps Script API-olvasás, valamint az ügyfél hozzáférési rekordja alapján készült. Teljes ügyféladat, jelszó és nyers privát napló nem került erre az oldalra. A részletes privát bizonyíték helyben marad.

A Google a szerverhibánál átmeneti szolgáltatáshibát, nem megfelelően jelzett kódhibát és Apps Script-hibát is felsorol. Emiatt a Google-hiba csak lehetséges ok. Google: hibaelhárítás. A jelenlegi általános futásidőkeret hat perc, ezért a 126 másodperc önmagában nem teljes futásidőtúllépés. Google: kvóták. Google: párhuzamos futások kizárása.