Hauptgedanke

Ein Hook-Ereignis namens Stop lässt an ein Ende denken: Man stellt sich vor, dass es ausgelöst wird, wenn man das Werkzeug schließt, einmal pro Sitzung. Tatsächlich wird es am Ende jedes Gesprächszugs ausgelöst – nach jeder vollständigen Antwort des Assistenten, ob sie aus einem Satz besteht oder fünfzehn Werkzeugaufrufe aneinandergereiht hat. Zwischen der Vorstellung und dem, was es tut, liegt ein Faktor von mehreren Dutzend.

Diese Abweichung ist kein Dokumentationsdetail, sie verändert, was man daran anschließen kann. Eine Verarbeitung, die für einen Lauf pro Tag gedacht ist – eine aufwendige Zusammenfassung, ein E-Mail-Versand, ein massenhafter Schreibvorgang –, wird in diesem Takt unbrauchbar. Umgekehrt bliebe ein Mechanismus, der jeden Austausch sehen muss, leer, wenn er nur beim Schließen ausgelöst würde.

Die tatsächliche Frequenz ist also das Erste, was man bei einem Hook-Ereignis klären muss, noch bevor man weiß, welche Daten es erhält. Der Name ist ein Hinweis auf die Absicht, keine Spezifikation.

Warum das wichtig ist

Der Fehler ist beim Schreiben nicht zu sehen: Der angeschlossene Code funktioniert, nur eben viel häufiger als geplant. Bezahlt wird er später, mit Kosten, Langsamkeit oder der Menge erzeugter Daten, und die Verbindung zum ursprünglichen Missverständnis wird selten hergestellt.

Allgemeiner gilt bei jeder Integration: Die Granularität eines Ereignisses ist ebenso zu prüfen wie sein Format.

Nuancen und Grenzen

Die tatsächliche Frequenz hängt auch von der Nutzung ab: Dasselbe Hook-Ereignis wird in einer intensiven Arbeitssitzung zwanzigmal ausgelöst und in einer kurzen Sitzung zweimal. Sie ist keine Konstante, die man ein für alle Mal feststellen kann.

Und der Name führt nicht immer in die Irre: Das Problem ist, ihn für eine Spezifikation zu halten, nicht, dass er etwas nahelegt.

Offene Fragen

• Wie prüft man die tatsächliche Frequenz eines Ereignisses, bevor man eine Verarbeitung daran anschließt, anders als durch Beobachtung in der Produktion?