enhancement
major
minor
defect
critical
major
minor
major
#29847
Der Skript-Test „TestTransactionMonitor-01_RevertRevision“ schlägt fehl, wenn eine geplante Aufgabe gleichzeitig eine Transaktion abschließt.
Problem
Der skriptbasierte Test „test/com/top_logic/demo/scripted/monitor/TestTransactionMonitor-01_RevertRevision.script.xml“ ist im nächtlichen Build TL7 #798 fehlgeschlagen:
Die Auflösung des ValueNamingScheme „com.top_logic.layout.scripting.recorder.ref.ChangeSetValueNaming“ ist fehlgeschlagen!
Lokales Objekt nicht gefunden: {revision=r4114}; Optionen: „ChangeSet [rev=4111, ... GELÖSCHT ... TestRevertRevision]“, ...
Analyse
Das Skript speichert die Revision seiner eigenen Commits in globalen Variablen unter Verwendung von „LastRevisionNamingScheme“, das auf die letzte Revision der Wissensdatenbank verweist (HistoryManager.getLastRevision()). Anschließend wählt es diese Revision im Transaktionsmonitor aus.
Im fehlgeschlagenen Durchlauf wurde das Löschen von „TestRevertRevision“ um 07:30:00.515 als r4111 festgeschrieben. Um 07:30:00.55 startete der Scheduler die halbstündlichen Aufgaben (CleanImageTmpDir, MailServerDaemon, RefreshUsersTask, SchedulerClusterCleanupTask), deren Aufgabenprotokolle als Systemrevisionen r4112–r4114festgeschrieben wurden. Der Variablen „Deleted TestRevertRevision“ wurde r4114 zugewiesen, eine Systemänderung, die der Transaktionsmonitor ausblendet (der Befehl „UpdateChangeSetTree“ zeigt nur Revisionen an, die von einer Person erstellt wurden). Daher schlug die Abfrage fehl.
Jede Verwendung von „LastRevisionNamingScheme“ bedeutet „die Revision der letzten Änderung des Skripts selbst“ und ist demselben Race-Bedingung ausgesetzt: die Skripte „TestComments-01_EditWithReadRight“, „TestShowHistoricObject-01_DeletedAttribute“, „TestHistoricObjectsWithScriptAttributes“, „TestUndo“, „TestRevisionAccess“, „TestRestoringDeletedObjectsWithDocuments“, „TestZipDownload-01_HistoricObject“, „TestDemo-72“, TestDemo-73, TestComparison-00 (teilweise über die Vorlage „Variable/Action-Variable-Revision merken.xml“) sowie mit „StoreCurrentRevisionCommand“ aufgezeichnete Aktionen.
Die Sitzungsrevision der Untersitzung des Skripts kann nicht stattdessen verwendet werden: „LiveActionExecutor.processAtomic()“ ruft nach jeder Aktion „MainLayout.globallyValidateModel()“ auf, wodurch die Sitzungsrevision auf die letzte Revision der Wissensbasis aktualisiert wird, bevor die nächste Aktion ausgeführt wird.
Änderung
„LastRevisionNamingScheme“ bezieht sich auf die letzte Revision, die von dem Benutzer, der das Skript ausführt, festgeschrieben wurde: die letzte Revision, deren Autor die Kontext-ID der Untersitzung des Aktionskontexts ist (die Kontext-ID, die bei einer Festschreibung dieser Untersitzung als Autor erfasst wird). Revisionen, die gleichzeitig vom System oder von anderen Benutzern festgeschrieben wurden, werden übersprungen.
„TestComments-01_EditWithReadRight“ speichert die Revision eines Kommentars, der vom Benutzer „testEditComment“ erstellt wurde; die Variablenzuweisung wird nun von diesem Benutzer (user-id="testEditComment") ausgeführt.
Migration
Ein Skript, das „LastRevisionNamingScheme“ nach einem Commit eines anderen Benutzers als demjenigen zuweist, der die Zuweisung ausführt, muss die Zuweisung als der commitende Benutzer ausführen (user-id von „SetGlobalVariableOp“).