ich bin heute Nachmittag durch die CLI-Referenz des Newton-Protokolls gegangen, diese langweilige Art von Dokumentation, die niemand von Anfang bis Ende liest. ich habe hauptsächlich nach genau einem Flag gesucht, das ich brauchte. am Ende bin ich dann völlig woanders gelandet.

im Policy-Client-Bereich liegen zwei Befehle direkt nebeneinander. set-policy, das festlegt, an welche Policy ein Client gebunden ist. und set-policy-params, das sich so anhört, als würde es nur die Einstellungen auf der Policy anpassen, die du bereits hast. ein Ablaufzeitfenster vielleicht. kleine Dinge.

es bleibt nicht klein. lies über die Flaggenliste hinaus, und die Doku sagt es ganz offen: set-policy-params ruft denselben internen setPolicy(PolicyConfig)-Registrierungspfad auf wie das direkte Umschalten von Policies, und es liefert jedes Mal eine neue policyId zurück, wenn es ausgeführt wird. die alte wird als veraltet markiert. also erzeugt ein Befehl, der sich liest wie „eine Einstellung anpassen“, denselben identity-level-Effekt wie ein Befehl, der sich liest wie „die Policy ersetzen“.

es lohnt sich, das kurz einen Moment lang gemeinsam zu betrachten.

man kann sehen, warum das so gebaut ist. Parameter und das Policy-Binding leben innerhalb desselben PolicyConfig-Records, also bedeutet das Anfassen eines Feldes das Schreiben eines neuen Records – Ende der Geschichte. Und es gibt einen echten Grund, dass das die richtige Entscheidung ist, nicht nur die bequeme.

wenn eine policyId dazu gedacht ist, auf etwas zu verweisen, das ein Beweis oder ein Audit-Trail sein kann, und man dem dauerhaft vertrauen können soll, dann darf sie nicht zu zwei unterschiedlichen Bedeutungen an zwei unterschiedlichen Punkten in der Zeit führen. Behalte dieselbe id nach einer Parameterversion bei – und du hast stillschweigend das Versprechen gebrochen, dass „policyId X“ immer auf eine unveränderliche Konfiguration verweist. Aus dieser Perspektive ist das Regenerieren der id kein Nebeneffekt. Es ist der eigentliche Punkt.

aber das macht die Schnittstelle nicht ehrlich darüber, was sie dir abverlangt.

auch das CLI behandelt set-policy-params intern ein wenig anders. Es nimmt --policy-client direkt entgegen, während die anderen policy-client-Subcommands sowohl --registry als auch --client wollen. Ein kleiner Hinweis darauf, dass dieser Befehl seine eigene Historie hat.

aber Flags sind nicht das, worum sich Leute bei der Erstellung von Tooling kümmern. Namen sind es.

all das taucht im Namen jedoch nicht auf. Ein Monitor, der Identitätsänderungen im Blick hat, aufgebaut um set-policy-Aufrufe herum, wird keinen davon bemerken. Eine Integration, die die policyId beim Setup einmal gecacht hat, hat keinen Grund zu denken, dass ein routinemäßiges Update der Parameter der Moment ist, in dem sie erneut nachladen muss. Korrektheit der Implementierung und Verständlichkeit des Befehlsnamens zeigen dabei in unterschiedliche Richtungen.

vielleicht ist die eigentliche Erkenntnis hier also kein Bug. Es ist, dass set-policy-params nicht unbeabsichtigt unterschätzt, was es tut: Es unterschätzt es im Namen, während es darunter das schwierigere, ehrlichere Ding macht.

ich bin mir noch nicht sicher, auf welcher Seite davon ich lande. Ist es richtig, bei jeder Parametervariation eine frische policyId zu erzwingen – als saubere Cache-Hygiene, die still und leise ihre Arbeit macht? Oder sorgt das Benennen eines Befehls für das kleinere der beiden Dinge, die er tatsächlich tut, dafür, dass jedes Integrations-Setup auf denselben überraschenden Effekt hereinfällt, getrennt voneinander, zu seiner eigenen Zeit?

@NewtonProtocol $NEWT #Newt $DODOX $VELVET