tests / release (push) Blocked by required conditionsDetails
Der Registereintrag nannte den falschen Grund: das Deaktivieren startet sehr
wohl eine Provisionierung. CustomDomainAccess::deactivate() ruft seit Langem
ReapplyInstanceAddress, das legt einen Lauf der `address`-Pipeline an und
schickt AdvanceRunJob auf die provisioning-Warteschlange; ConfigureNextcloud
loescht dort trusted_domains 2 und ConfigureDnsAndTls schreibt den Router ohne
den Namen neu. Das ist gebaut und geprueft.
Der Schaden war trotzdem echt, nur eine Tuer weiter. Erreicht wurde deactivate()
allein ueber PlanChange::settleCustomDomain, also ueber den Paketwechsel. Der
zweite und haeufigere Weg, auf dem das Recht endet — der Kunde bucht das Modul
in der Abrechnung ab, clupilot:end-cancelled-addons haelt den Termin am Ende des
bezahlten Zeitraums — ging an dieser Stelle vorbei: BookAddon::cancel() lieferte
Speicher nach und sprach mit Stripe, fragte aber niemanden nach der Adresse. Die
Domain verschwand aus jeder Ansicht und blieb auf der Maschine stehen.
BookAddon::cancel() fragt jetzt CustomDomainAccess::enforce() — die ganze Regel,
nicht den Modulschluessel: wer von Team auf Business aufgestuft hat und sein
altes Modul loswird, behaelt die Domain, weil das Paket sie selbst traegt.
Und der Anstoss darf die Entscheidung nicht kippen. deactivate() faengt jetzt
einen Fehlschlag der Nachfuehrung ab und schreibt ihn als Fehler ins Log: die
Wahrheit steht in der Datenbank, die Maschine zieht nach, und eine Kuendigung
haengt nicht daran, ob ein fremder Host gerade antwortet.
Die Gegenrichtung brauchte nichts: der Entzug loescht die Domain-Spalte, also
traegt der Kunde sie nach der Neubuchung neu ein und weist sie neu nach — und
genau dort haengt seit jeher der Lauf, der sie wieder ausliefert. Ein Test haelt
das fest, damit es keine Einbahnstrasse wird.
Registereintrag gestrichen.
Rot gesehen: ohne den settleCustomDomain-Aufruf fallen drei der vier neuen
Tests; ohne das try/catch faellt der vierte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"Ein Plan-Wechsel wird nirgends angewendet" stimmt seit laengerem nicht mehr.
ApplyPlanChange faehrt die plan-change-Pipeline, aufgerufen vom OrderObserver
bei einer Aufstufung und von clupilot:apply-due-plan-changes bei einer
Abstufung zum Laufzeitende. settleCustomDomain() hat sehr wohl einen Aufrufer
(ApplyPlanChange:256), und sieben Testdateien mit 43 Pruefungen decken den Weg.
Aufgeschrieben, weil der Kopfkommentar dieser Datei genau das ausschliesst:
"Ein Punkt verschwindet, wenn die Arbeit im selben Commit fertig wird, der ihn
streicht — und damit kann die Liste nicht behaupten, etwas sei offen, das es
laengst nicht mehr ist." Genau das ist passiert. Wer eine Liste fuehrt, deren
einziger Zweck Ehrlichkeit ist, muss sie mit der Arbeit streichen, nicht
danach.
Gepruefte Restliste: neun Punkte. Zwei davon (zweiter Sicherungsort, Office
Pro) haengen an Infrastruktur, die es noch nicht gibt; einer (Hostnamen-
Abnahme) an der echten Anlage; einer (Support-Mail) an einem SMTP-Konto, das
der Betreiber anlegen muss.
nexxo