In mehreren Kalendern können Termine denselben Titel tragen.
Das Problem: Mehrdeutige Termine
Ein Assistent liest mehrere private, geschäftliche und geteilte Kalender. Ein gleich benannter Termin ist dabei kein eindeutiger Verweis. Ein fehlgeschlagener Abruf darf außerdem nicht wie ein leerer Kalender behandelt werden: Sonst plant der Assistent in eine nur scheinbar freie Zeit.
Die Lösung: Herkunft mitführen
Eve bewahrt die Kalender-ID zusammen mit der Ereignis-ID. Die Routenreferenz trägt diese Herkunft ebenfalls. Mehrdeutige Ereignisverweise werden abgelehnt. Ein fehlgeschlagener Abruf eines ausgewählten Kalenders wird nicht als freier Zeitplan ausgegeben.
Konkurrierende Änderungen erkennen
Beim Anlegen werden stabile Ereignis-IDs verwendet. Vor Verschieben oder Löschen wird die Version gelesen und mit If-Match geprüft. Zwischenzeitliche Änderungen werden dadurch nicht einfach überschrieben. Änderungen werden nicht automatisch wiederholt.
Unterschiedliche Prüfstände
Das Protokoll vom 5. Oktober nennt eine erfolgreiche Live-Auflistung von elf Kalendern. Bei der Implementierungsprüfung der Schreibfunktionen wurde dagegen kein echter Termin verändert. Die beschriebene Unterstützung gilt für zeitgebundene Einzeltermine, nicht für ganztägige Termine oder Serienbearbeitung. Eine erfolgreiche Kalenderauflistung bestätigt somit nicht sämtliche Bearbeitungsfunktionen.
Der Name ist keine Identität
In mehreren Kalendern können Termine denselben Titel tragen. Auch eine Ereignis-ID darf nicht ohne ihren Kalenderbezug weitergegeben werden. Der Kalender, in dem gesucht wurde, gehört deshalb zur Ergebnisstruktur. Für spätere Werkzeuge bleibt das Paar aus calendar_id und event_id erhalten. Andernfalls kann ein Agent die richtige Formulierung anzeigen und trotzdem das falsche Ereignis ändern. Die Verknüpfung darf außerdem nicht allein aus einer frei formulierten Antwort rekonstruiert werden. Das Werkzeug erhält eine explizite Referenz und lehnt eine mehrdeutige Auswahl ab.
Verfügbarkeit ist ein vollständiger Leseschritt
Bei der Planung werden alle ausgewählten Kalender gelesen. Ein Fehler in einem Kalender ist ein unbekannter Teil des Zeitplans, keine leere Liste. Das ist wichtig, wenn ein geschäftlicher Kalender ausfällt, während ein privater erfolgreich antwortet. Eine zusammengeführte Liste mit nur privaten Terminen würde frei aussehen und dennoch unvollständig sein. Wir behalten deshalb den Fehlerzustand bei und lassen ihn nicht in einem allgemeinen Ergebnis mit freien Zeitfenstern verschwinden. Die erfolgreiche Live-Auflistung von elf Kalendern prüfte den realen Zugang; Fehler- und Mehrdeutigkeitsfälle benötigen zusätzlich gezielte Gegenproben.
# Reduziertes Muster aus dem Kalender-Writer.
existing = await calendar.get(
"events/" + event_id, calendar_id=calendar_id)
etag = existing.get("etag")
if not isinstance(etag, str) or not etag:
raise ValueError("Missing event version")
response = await client.patch(
event_url,
headers={"If-Match": etag},
json={"start": new_start, "end": new_end})
if response.status_code == 412:
raise RuntimeError("Event changed; read and review again")Warum vor PATCH nochmals gelesen wird
Zwischen Planung und Ausführung kann eine Person den Termin ändern. Der Kalender-Writer liest deshalb vor der Änderung die aktuelle Ressource und deren ETag. Der anschließende Request sendet If-Match. Hat sich die Ressource seit dem Lesen verändert, kann der Server die Änderung zurückweisen. Im reduzierten Beispiel wird ein 412-Status als Konflikt behandelt. Wichtig ist die Konsequenz: Der Agent darf nicht sofort dieselbe Änderung ohne Versionsprüfung wiederholen. Er muss den neuen Zustand lesen und die Entscheidung erneut bewerten. Google beschreibt dieses Verfahren in der Dokumentation zur Ressourcen-Versionierung.
Technische Referenz: Google Calendar: Ressourcen-Versionierung.
Anlegen benötigt einen anderen Schutz
Beim Erstellen eines Termins gibt es noch keine vorhandene Version. Hier nutzt die Implementierung eine stabile ID aus den wesentlichen Ereignisdaten. Nach einer Duplikatantwort wird das bestehende Ereignis geprüft, statt ein zweites anzulegen. Das verhindert einen bestimmten Wiederholungsfall, macht aber nicht jede Kalenderoperation beliebig wiederholbar. Verschieben und Löschen bleiben zustandsabhängige Änderungen. Während der Implementierungsprüfung wurde kein echter Termin geschrieben. Diese Grenze ist wichtig: Die Leserprüfung und der Code für Schreibschutz sind belegt, eine neue Ende-zu-Ende-Bearbeitung eines realen Termins wird daraus nicht behauptet.
Weiterlesen: Hintergrundagenten: Nach einem Neustart nicht alles wiederholen.