@camunda/e2e-test-suite 0.0.1175 → 0.0.1176

package/dist/tests/8.10/optimize-agentic-control-panel-api.spec.js

@@ -8,6 +8,16 @@ const users_1 = require("../../utils/users");
 const agenticDashboardHelpers_1 = require("../../utils/agenticDashboardHelpers");
 const testUser = (0, users_1.getTestUser)('twentyFirstUser');
 const clusterName = 'Test Cluster';
+// No reason for serial has been established here, and it is kept rather than
+// flipped only because nobody has measured either way. All five tests are
+// read-only against the agentic dashboard (the one interaction,
+// changeDashboardDateRange, is a view-local Carbon dropdown), so there is no
+// shared state to protect. Serial does NOT cut login volume either: beforeEach
+// runs per test, so it is five logins as twentyFirstUser either way, and that
+// user is also used by navigation, optimize-agentic-control-panel-ui and
+// saas-migration-path-user-flows, none of which are serial. Rate-limit hits are
+// absorbed by loginWithRetry and have never been traced to a failure
+// (docs/saas-login-investigation.md). See docs/serial-specs.md.
 _8_10_1.test.describe.configure({ mode: 'serial' });
 _8_10_1.test.describe('Agentic Control Plane Dashboard API Tests @agentic-dashboard-api @8.10', () => {
     _8_10_1.test.beforeEach(async ({ page, loginPage }, testInfo) => {

package/dist/tests/8.10/optimize-data-filters-api.spec.js

@@ -4,6 +4,16 @@ const test_1 = require("@playwright/test");
 const _8_10_1 = require("../../fixtures/8.10");
 const apiHelpers_1 = require("../../utils/apiHelpers");
 const sleep_1 = require("../../utils/sleep");
+// Serial is load-bearing twice over. Ordering: T11728029 asserts a business_*
+// pattern is present in the default, untouched includeVariableNames, and the
+// three variableFilter writers below (T11728020, T11728034, T11735087) replace
+// that list -- so T11728029 has to run before them, which parallel mode cannot
+// guarantee. (T11735088/T11735089 write processDefinitionFilter instead, and
+// T11728030/T11728019 write nothing.) Snapshot:
+// beforeAll reads the live config into originalFilters and afterAll writes it
+// back; in parallel each worker runs beforeAll, so a worker starting second
+// would snapshot another worker's mutation and restore that as "original",
+// leaving the shared cluster dirty after the run. See docs/serial-specs.md.
 _8_10_1.test.describe.configure({ mode: 'serial' });
 let managementToken;
 let clusterUuid;

package/dist/tests/8.10/optimize-data-filters-ui.spec.js

@@ -17,6 +17,13 @@ let dataFiltersAvailable = false;
 const skipIfUnavailable = () => {
     _8_10_1.test.skip(!dataFiltersAvailable, 'Data Filters section is not available on this cluster (feature not yet enabled)');
 };
+// Serial is load-bearing: these 18 tests drive the same Console Data Filters
+// form for the same cluster, and several of them Save and reload to assert
+// persistence -- the same whole-config write the API spec issues, just from the
+// browser. The Read-only operator describe also asserts the fields are not
+// editable, which only holds if nobody else is mid-edit. The client-side
+// negative tests would survive parallelising on their own, but they share the
+// form with the ones that save. See docs/serial-specs.md.
 _8_10_1.test.describe.configure({ mode: 'serial' });
 _8_10_1.test.describe('Optimize Data Filters UI @optimize-data-filters-ui @8.10', () => {
     _8_10_1.test.slow();

package/dist/tests/8.10/optimize-exporter-filters-importer-e2e.spec.js

@@ -5,6 +5,16 @@ const _8_10_1 = require("../../fixtures/8.10");
 const apiHelpers_1 = require("../../utils/apiHelpers");
 const randomName_1 = require("../../utils/randomName");
 const sleep_1 = require("../../utils/sleep");
+// Serial is load-bearing: the two describes below each request a DIFFERENT
+// exporter setting on the same cluster-wide singleton in beforeAll
+// (variableValueTypeExclusion: ['Object'] vs optimizeModeEnabled: true), then
+// assert on what Optimize actually imported over a ~180s poll. These are
+// PARTIAL updates, not whole configs -- setFilters below re-reads the live
+// config and sends {...current, ...config}, so in declaration order the second
+// beforeAll inherits ['Object'] from the first. Serial order is what makes that
+// inheritance deterministic; run concurrently, each beforeAll read-modify-writes
+// on top of whatever the other left behind and which settings are active during
+// an assertion depends on interleaving. See docs/serial-specs.md.
 _8_10_1.test.describe.configure({ mode: 'serial' });
 const VARIABLE_DEFINITION_FILE = './resources/Job_Worker_Process.bpmn';
 const VARIABLE_DEFINITION_KEY = 'Job_Worker_Process';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camunda/e2e-test-suite",
-  "version": "0.0.1175",
+  "version": "0.0.1176",
   "description": "End-to-end test helpers for Camunda 8",
   "repository": {
     "type": "git",