# Session fbcc7342 — RwG: Produktion war von Google abgeschaltet, Support-Fall laeuft

## GOOGLE HAT GEANTWORTET (06.09. 20:07, Marlou, Fall 05599496)
- Onboarding-Meilensteine sind IRRELEVANT ("integration has been already launched").
  Der ganze Buchungsverkehr-Strang entfaellt. Meine Sackgassen-Analyse war falsch.
- DISH ist KEIN Hindernis, mehrere Partner je Merchant sind erlaubt.
- Merchant-Zahl 23 und Sandbox-404 werden intern beraten.
- ENTSCHEIDEND: "As long as you provide the availability for that merchant your integration
  should be enabled for them." Der Availability-Feed ist damit der Hauptweg, nicht mehr ein
  Nebenschauplatz.
- ANTWORT LIEGT FERTIG: projekte/rwg-prod-uebernahme/support-antwort-2.md mit Durranis
  Merchant-ID. EMPFEHLUNG: erst nach dem Feed-Lauf morgen senden, dann mit Nachweis statt
  Ankuendigung.

## ERLEDIGT am 06.09. abends: Availability-Feed laeuft, Brief ist raus
- Feed per AppConfig-Ausloeser getriggert (Deployment 10 = Version 2, danach 11 = Version 1
  zurueckgestellt und die aktive Konfiguration gegengeprueft: wieder "0 0 5 * * *").
- Ergebnis: Availability_Feed_production_1788719523.json.gz, 06.09. 20:32 CEST, 1 Shard,
  0 Issues, 0 Errors. **Erste Availability-Zeile ueberhaupt in der Produktion.**
  Diagnose bestaetigt: der fehlende Sonntag bei ALIBABA brach den Feed fuer alle 23 ab.
- "Processing / 0 records" ist KEIN Befund. Sandbox-Gegenprobe: dort stehen Zeilen tagelang so,
  waehrend andere desselben Tages 118.260 Datensaetze zeigen.
- Selbstbewusst umgeschriebener Brief an Marlou GESENDET (Fall 05599496) mit Durranis
  Merchant-ID, dem Dateinamen als Nachweis und der Bitte um Wiedereinschaltung.

## GOOGLE HAT ZWEIMAL GEANTWORTET (06.09. abends)
1. Marlou: Meilensteine irrelevant, DISH kein Hindernis, Merchant-Zahl und 404 intern in Beratung.
2. Donna (dieselbe Person, die am 21.07. abgeschaltet hat), 21:05 auf unseren Brief:
   "Regarding re-enabling your integration, we have escalated this with our team. We will reach
   out to you once we have an update."
   -> Der Fall liegt bei der Entscheiderin und ist aus dem Support heraus eskaliert.

## NAECHSTER SCHRITT: WARTEN, NICHT ANTWORTEN
Kein "danke" schicken — das schiebt unsere inhaltliche Nachricht im Verlauf nach unten.
Der letzte inhaltliche Beitrag im Fall soll unserer sein.

**NACHFASSEN AM DONNERSTAG, 10.09.2026**, falls bis dahin nichts kommt: kurzer Dreizeiler
ueber "Follow Up On Case" in Fall 05599496. Nicht frueher — sie haben am 06.09. innerhalb
weniger Stunden zweimal geantwortet.

## MORGEN (07.09.)
Feed laeuft regulaer 05:00 UTC. Nur bei Auffaelligkeiten melden — die Availability-Frage ist
beantwortet.

## Wo wir stehen
- **Ursache gefunden:** Google hat die Produktions-Anbindung am 21.07.2026 ABGESCHALTET
  (Fall 05487612, "Failure: Providing 1 merchant", Bedingung "no fewer than 25").
  Vorgeschichte: 02.07. Merchants fielen von 35 auf 1, drei unbeantwortete Nachfragen.
  Deshalb: Feeds werden angenommen (23 Datensaetze, 0 Fehler), Inventory bleibt bei 1,
  Durrani haengt auf "Processing". Auf unserer Seite ist nichts kaputt.
- **Support-Fall laeuft:** Issue 05599496, "Follow up on case ...-05487612", OPEN seit 06.09.
  Category "Technical issue", Reason "Integration is down". Entwurf in
  projekte/rwg-prod-uebernahme/support-mail-entwurf.md.
  Wenn bis Mitte naechster Woche nichts kommt: nachfassen, der Fall ist offen.
- **23 Betriebe live** in der Produktion, alle mit geprueften Place-IDs auf echte Betriebe,
  Oeffnungszeiten, echten Tischplaenen, Telefonnummern.
  Kais hat entschieden, bei 23 zu bleiben statt auf 25 zu gehen (meine Empfehlung war 25,
  weil Google es viermal woertlich schreibt). Die Mail nennt die 23 offen und greift Googles
  eigenes Angebot auf, ueber Abweichungen zu beraten.

## AWS-Kosten (06.09. analysiert, aws-kosten-analyse.md)
Der Anstieg von 171 auf 240 USD war die Log-Gruppe /ecs/backend-staging-debug: 2,73 GB taeglich
aus einer Fehlerschleife (rotierte statische AWS-Schluessel, UnrecognizedClientException).
SEIT 31.08. VORBEI, behoben durch Commit 8cd046cd. September landet bei rund 155 USD.
Meine erste Diagnose (Datadog-Metrikabfragen) war FALSCH — die machen 3,41 USD aus.
ERLEDIGT 06.09.: Elastic IP 18.153.167.91 freigegeben (5 verbleiben, alle zugeordnet).
Restliche Hebel, alle klein:
Datenbanken auf privat (7 USD, beide haben PubliclyAccessible true — auch ein Sicherheitspunkt,
vorher klaeren wer sich von aussen verbindet), Staging nachts abschalten (15-20 USD).
NICHT anfassen: assignPublicIp der ECS-Aufgaben, die brauchen es (kein NAT-Gateway vorhanden).

## Kostenwache laeuft (seit 06.09.)
/home/aria/projekte/aws-kostenwache/ — kostenwache.py plus melde.sh, in der Nutzer-Crontab
taeglich 07:12 UTC. Schweigt im Normalfall, montags kommt der Bericht immer.
Schwelle: mehr als 25 % Zuwachs UND mehr als 5 USD gegenueber demselben Zeitraum des Vormonats.
Manuell: `python3 kostenwache.py --bericht` (Cost Explorer braucht us-east-1, das Skript setzt es).
Die Steuer wird herausgerechnet, weil sie als Klumpen gebucht wird und jede Hochrechnung verzerrt.

## AWS-Rechte
aria-automation hat jetzt zusaetzlich die Inline-Richtlinie `aria-automation-only-read`:
CloudWatch Logs lesen, AppConfig lesen (App 540vb0a inkl. Deployments), SES lesen,
Cost Explorer lesen. Ausschliesslich lesend — Schreibrechte bewusst abgelehnt.
Cost-Explorer-Aufrufe brauchen `--region us-east-1`.
Datadog: mein Schluessel gehoert zu einer ANDEREN Organisation als die, die die
Produktions-Logs empfaengt (sha256-Praefixe 431a4b8a vs aa8ba091). Deshalb null Treffer.
Offen: API- und Application-Schluessel aus der richtigen Organisation.

## Offen (NICHT adesso — kadicon ist Kais' eigenes Repo, adesso gehoert nur zu SupplierPulse)
1. ERLEDIGT: **PR 279 gemergt** (8a874118). settings save() liest die Zeile wieder vollstaendig.
2. ERLEDIGT: **PR 280 und 281 gemergt**, Richtlinie in der AWS-Konsole nachgezogen, Versand
   dreifach mit HTTP 204 verifiziert. Staging verschickt wieder Mails.
   ACHTUNG: Damit ist der unbeabsichtigte Schutz weg — Testbuchungen in der Sandbox schicken
   wieder echte Mails an die Wirte. Vor weiteren Buchungstests einen Testbetrieb mit einer
   nicht weiterleitenden Adresse anlegen (kais@kadicon.de leitet nicht weiter).
   NICHT `nx run infra:apply` ausfuehren: infra/src/envs/staging.tfvars liegt nicht im Repo
   (.gitignore, enthaelt Live-Secrets). Ein Apply ohne die Datei faesst den ganzen Stack an.
3. **Produktions-Beobachtbarkeit**: keine CloudWatch-Gruppe, Datadog-Schluessel liefern 0 Treffer,
   kein Leserecht auf die Prod-AppConfig. Bei Stoerungen in der Produktion bin ich blind.
4. **Durrani laeuft buchungsseitig ueber DISH.** Googles Buchungsseite nennt DISH als Partner.
   Selbst nach der Freischaltung wuerde Google dort nicht auf KADiCon umschalten. In der
   Support-Anfrage sachlich angesprochen, ohne den Wettbewerber zu nennen.
5. **Izmir Kebap Haus und Grill & Doener Haus by Theo** bleiben zurueckgestellt. Fuer eine
   spaetere Aufschaltung fehlen Telefonnummer und Tischplan. Place-IDs sind ermittelt:
   ChIJMZU-BQC3oEcRO1BnNJJOkZU und ChIJUQH5VgB9vkcRDQztf55d9A8.
6. SupplierPulse, NEU am 07.09.: David Koenig hat PR #513 hinterfragt. Ergebnis nach zwei Runden:
   adessos Konvention ist "Feature-Beschreibung ins Issue" (Grund: Aenderungstempo waehrend der
   Entwicklung). Kais passt sich an. AUFTRAG: beschreibende Dokumente in die Issues, PR #513
   schliessen, und das PMO so schneiden, dass es in wenigen Tagen fertig werden kann.
   Mein Vorschlag liegt bei Kais: nur die technischen Vertraege einarbeiten, unser
   Analysematerial (Risikoregister, Abhaengigkeitskarte, IA, SharePoint-Bewertung) NICHT
   abladen; Kern = 490/492/494/496 (benutzbarer Berichtskreislauf), Aufgabenliste 500/501 als
   eigenes Feature herausloesen. Offene Rueckfrage an Dave: jedes Ticket in Tagen oder das
   ganze PMO in Tagen? Aufwand geschaetzt halber bis ganzer Tag. Wartet auf Kais' Go.
   Material: projekte/supplierpulse-enterprise-assist/modules/pmo-konsolidierung/

## Wichtigste Erkenntnis zum Booking-Server-Verkehr
Googles Zaehler (1 von 20 BatchAvailabilityLookup) registrieren nur Anfragen, die VON GOOGLE
kommen — belegt dadurch, dass Google fuer die eine Anfrage vom 29.08. eine Latenz misst.
Unser eigenes Werkzeug tools/rwg/booking-server-e2e.ts zaehlt NICHT. Es ist trotzdem wertvoll:
Lauf am 06.09. bestand alle 11 Schritte, unser Booking-Server arbeitet also nachweislich korrekt.
Sandbox-Buchungsseiten liefern 404 oder verlangen ein Client-Zertifikat, das KADiCon nicht hat.
=> Sackgasse, nur ueber Google aufloesbar. Genau das fragt die Support-Anfrage.

## Werkzeuge
- **Onboarding neuer Restaurants:** projekte/rwg-prod-uebernahme/onboarding/ (onboard.py mit
  pruefen/mail/anlegen, zeiten.py, ANLEITUNG.md). Prueft den Google-Eintrag inkl. Namensabgleich
  und schaltet erst ein, wenn an jedem geoeffneten Tag Zeitfenster entstehen.
- projekte/rwg-prod-uebernahme/: anlegen.py, kadicon_settings.py, prod-kennungen.txt,
  eingabe-ausgefuellt.csv, BEFUNDE.md (B1 bis B9), BEFUND-produktion-abgeschaltet.md
- .secrets/prod.env (info+alibaba@kadicon.de / kadicon123, Muster fuer alle 22)
- .secrets/durrani.env (aseckzai@gmail.com fuer Tenant 4e22f973)

## HARTE REGELN
- **POST /settings ersetzt den gesendeten Block, es merged NICHT** (B1). Immer den VOLLSTAENDIGEN
  Block senden, inklusive googlePlaceId und timezone. Sonst sind sie weg, ohne Fehlermeldung.
- **Auf /settings/restaurant in der Oberflaeche NICHT speichern**, das loescht die Place-ID.
- **Testbuchungen loesen Mails an den Wirt aus** (sendOwnerEmail an settings.restaurant.email,
  die info+-Aliasse leiten an die Laeden weiter). Aktuell faellt das nur aus, weil Staging kein
  SES-Recht hat. Nach dem SES-Fix gilt die Warnung wieder.
- Zeitstempel nur aus `date` (Server laeuft UTC).