[Flakey Test] json-field-roundtrip.spec.ts: JSON value read before Monaco renders; Title fill sometimes lost before save

Flaky test

core-web/apps/dotcms-ui-e2e/src/tests/edit-content/fields/json-field/json-field-roundtrip.spec.ts:42
— "a JSON value survives save and reopen, still indented" (@critical)

The test is intermittent across unrelated branches and also fails on a clean main build. Because the PR pipeline is fail-fast, a failure in this E2E shard cancels the Integration MainSuites and several Postman collections, so the PRs it hits get no backend validation.

Evidence

CI history: the test shows up in Playwright's failed/flaky list in 17 PR E2E jobs from 2026-09-30 to 2026-10-02, across unrelated branches: issue-37764-daisyui-modal-page-backdrop, issue-23628-management-api, 37759-content-drive-open-legacy-editor-content-in-the-side-panel, upgrade-tinymce-legacy-version, issue-37665-content-drive-adaptive-chunk-impl, 37846-sync-site-workflows, issue-37676-examples-error-details, issue-37683-events-prototype. It also failed on every retry in fix(maven): publish nested-group release artifacts #37855 (CI-script changes only) and in fix(index): write and read the reindex index-name timestamp in UTC (#37282) #37853 (backend-only).
Local, clean main (d4a354c1f8): it fails with the same CI error.
Local, two other builds: with --repeat-each=5, one build passed 3 of 5 and the other passed 1 of 5.

Two failure modes

Empty editor after reopen (the CI error): expect(rendered).toContain('alpha'), received "". The failure screenshot shows the content saved and reopened, with the JSON fully rendered and indented (4 lines). The data round trip works. The assertion reads editor.innerText() once, immediately after toBeVisible(), before Monaco has painted the lines.
Save never happens: the new-content form shows "Some required fields need your attention", Title is empty, and the JSON has been typed. save() then ends in page.waitForResponse: Page closed. The Title fill appears to be lost before saving, likely to a race with the Monaco editor taking focus or the form re-initialising. Not confirmed.

Suggested fix

For mode 1, replace the one-shot innerText() read with retrying assertions, e.g. await expect(editor).toContainText('alpha'), or poll until the editor has more than one line.
For mode 2, assert that Title still holds its value right before save(), or fill Title after typing into Monaco. The underlying form race should be investigated.

Repro

cd core-web
CURRENT_ENV=ci HEADLESS=true ./node_modules/.bin/playwright test \
  -c apps/dotcms-ui-e2e/playwright.config.ts \
  apps/dotcms-ui-e2e/src/tests/edit-content/fields/json-field/json-field-roundtrip.spec.ts \
  --repeat-each=5 --workers=1

Run it against dotCMS on :8080.

Update: this looks like a form race, not only a test-timing issue

I tried two test-only fixes locally:

replacing the one-shot innerText() with retrying toContainText / expect.poll;
filling Title after typing into Monaco, then asserting toHaveValue.

The test got worse: 7 of 8 runs failed. Those failure screenshots show a different picture from the original run.

Original order (Title first, then JSON): Title is sometimes lost. The form shows "Some required fields need your attention" and the save never happens.
Reversed order (JSON first, then Title): the content saves with Title but with an empty Payload. After reopen, the editor shows one blank line, still empty after the 5 s retry. The JSON was lost before save.

So in both orders, the first field edited right after the new-content form opens can be wiped. That matches the rebuild effects in DotEditContentFormComponent (dot-edit-content-form.component.ts). They call initializeForm() again when store state changes, and the in-code comment already notes that rebuilding "races with async child components ... and can wipe the user's current selection". The hypothesis is that a rebuild lands after the user starts typing. Which effect fires on a new-content form has not been confirmed.

If that holds, real users who type quickly after opening a new content form could hit it too, not just E2E. A test change alone will not fix it reliably; the form needs either to stop rebuilding once the user has interacted, or to expose a "form ready" signal that the test (and the UI) can wait on.

The original one-shot-read problem is also real. In one failing run, the screenshot showed the JSON saved and rendered while the test had read "". The retrying assertion should land together with the form fix.

@nicobytes

PRs linked to this issue

test(edit-content): wait for the real Monaco editor in the JSON round-trip e2e (#37870) by @nicobytes

core-web/apps/dotcms-ui-e2e/src/tests/edit-content/fields/json-field/json-field-roundtrip.spec.ts:42 looks like where this lives — the work reads as: json-field-roundtrip.spec.ts: json value read before monaco renders; title fill….

Can put together a PR against this branch if it's still open.

Navigation Menu

Repository navigation

[Flakey Test] json-field-roundtrip.spec.ts: JSON value read before Monaco renders; Title fill sometimes lost before save #37870

Flaky test

Evidence

Two failure modes

Suggested fix

Repro

Update: this looks like a form race, not only a test-timing issue

PRs linked to this issue

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Flakey Test] json-field-roundtrip.spec.ts: JSON value read before Monaco renders; Title fill sometimes lost before save #37870

Description

Flaky test

Evidence

Two failure modes

Suggested fix

Repro

Activity

fabrizzio-dotCMS commented on Oct 2, 2026

Update: this looks like a form race, not only a test-timing issue

github-actions commented on Oct 2, 2026

PRs linked to this issue

shoaibyazdani commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions