Markdown herunterladen Originaldokument auf GitHub

Korrektur der Nebenläufigkeit bei Launch-Planproduktzuordnungen

AUTH-03 aus der Autorisierungsprüfung wurde behoben. Nur der Launch-Server und zugehörige Regressionstests wurden geändert; keine Bereitstellung und keine SDK-Veröffentlichung. Die Grenze der Autorisierungsentscheidungen von Licentivo und SDK bleibt unverändert.

Änderungen

Beim Speichern einer Zuordnung wird in der Transaktion zuerst der gemeinsame Launch-Produktdatensatz und dann die Planversion gesperrt. Speicheranfragen verschiedener Pläne oder Prozesse halten dadurch dieselbe Produktsperre ein; konfliktierende Anfragen geben HTTP 409 PRODUCT_MAPPING_CONFLICT zurück.
products.licentivo_product_id speichert eine stabile öffentliche Produktroute. Nach dem ersten erfolgreichen Speichern einer Zuordnung können andere Pläne desselben Launch-Produkts nur dieses Licentivo-Produkt wählen; unterschiedliche Richtlinien dafür sind erlaubt. Das Feld speichert keine Funktionsberechtigungen, Gerätequoten oder Kundenautorisierungszustände.
Die Kundenidentität liest die stabile Route und wählt das Produkt nicht mehr anhand der höchsten Version über alle Pläne. Auch bei Planveröffentlichung und Erstellung der SDK-Integrationskonfiguration wird dieselbe Bindung geprüft.
Alte Datenbanken erhalten automatisch ein nullable Feld. Bei Daten ohne stabiles Feld werden der Reihe nach Kaufhistorie wie bezahlte Käufe, historische Veröffentlichungen und übrige Zuordnungen herangezogen; bei mehreren Produkten derselben Priorität wird ein Konflikt ausdrücklich gemeldet, statt zu raten. Ein eindeutiges gekauftes Produkt hat Vorrang vor einem unzusammenhängenden Entwurf; anschließend kann eine kompatible gespeicherte Zuordnung die Bindung festschreiben. Produktinhaltsbearbeitung behält die Bindung.

Historische fehlerhafte Daten, die bereits an mehrere Licentivo-Produkte verkauft wurden, erfordern weiterhin manuelle Prüfung; Kaufdatensätze oder Remote-Lizenzen werden hierbei nicht überschrieben. Wenn ein anderes Licentivo-Produkt verwendet werden soll, muss ein neues Launch-Produkt erstellt werden; ein neuer Plan darf die ursprüngliche Produktroute nicht überschreiben.

Implementierung siehe Zuordnungsspeicherung, Produktrouting, Identitätsausstellung, Veröffentlichungsprüfung, Integrationsprüfung, Datenmodell.

Lokale Verifikation

Prüfung	Ergebnis
Vergleich mit der Implementierung vor der Korrektur	Derselbe Regressionstest erfasst zuverlässig, dass zwei konfliktierende Speichervorgänge gleichzeitig erfolgreich waren, und schlägt erwartungsgemäß fehl
Gezielte Zuordnungsregression nach der Korrektur	Eine konfliktierende Anfrage erfolgreich, eine 409; beide kompatiblen Speichervorgänge erfolgreich; Identität nach Zahlungssynchronisierung nicht durch falschen Entwurf beeinflusst; SDK-Integrationsschicht akzeptiert korrekten Produktkontext
Schutz historischer Daten	Gekaufte Route vorrangig, Fehler bei Mehrdeutigkeit, Veröffentlichung falscher Entwürfe verboten, keine SDK-Konfiguration aus falscher historischer Veröffentlichung und Bindung bei Inhaltsbearbeitung erhalten: alle bestanden
Alle Go-Quellpakete und MySQL-Regression	192 bestandene Testeinträge einschließlich Unterfällen; keine Fehler. `TestProductUploadRoundTrip` übersprungen und nicht als bestanden gezählt
Strukturupgrade alter Datenbanken	Struktur ohne Routenspalte erhält bei Initialisierung das nullable Feld; erneute Initialisierung bestanden
Integrationstest mit echtem Launch, Licentivo und Go SDK	13 Geschäftsphasen bestanden, einschließlich Kauf, tatsächlicher signierter Funktionsausführung, Wiederherstellung nach normalem Schließen, Logout, Remote-Entbindung, alter Generation, Verlängerungserstattung, Kontowiderruf und Ausführungsverweigerung nach Erstattung/Chargeback
Abschließende Ergänzungsprüfung	Gezielte Zuordnungsregression in neuer leerer Datenbank bestanden, einschließlich Integrationskonfigurationsprüfung historischer Veröffentlichungen; `go vet` bestanden

Nach vollständiger Regression und Integrationstest mit echten Diensten wurde zuletzt eine Konsistenzprüfung der SDK-Integrationsprüfung ergänzt; die gezielte Regression mit diesem Szenario und go vet wurden separat erneut ausgeführt. Das erwartete Fehlschlagen der alten Implementierung belegt, dass der Test die ursprüngliche Race Condition erkennt, und ist kein ungelöster Regressionsfehler.

Der Integrationstest verwendete ein separates lokales MySQL 8.0.32, den aktuellen Licentivo-Dienst und das tatsächliche Go SDK; Zahlungsanbieter und DeepL verwendeten isolierte simulierte Dienste, ohne tatsächliche Abbuchung oder kostenpflichtige Übersetzung. Gezielte Tests zu Nebenläufigkeit und historischen fehlerhaften Zuordnungen verwendeten echte Launch-Geschäftslogik, MySQL und einen Protokollsimulator; es wird nicht behauptet, dass alle neun SDKs in dieser Runde einen Integrationstest mit echten Diensten abgeschlossen haben.

In dieser Runde wurde 192.168.2.177 nicht aufgerufen. Die hierfür gestarteten temporären MySQL- und Licentivo-Prozesse wurden gestoppt, bestehende Dienste blieben erhalten. Originalmaterial liegt im ignorierten Verzeichnis .local/mapping-fix-20261024/; eine teilbare Zusammenfassung siehe Verifikationsnachweise.