How many of the e2e tests could run in parallel?

Short answer: nearly all of them. Of the 264 runnable specs across both suites, ~230 (87%) are parallel-safe by design. Only 3 specs truly depend on a previous test's output, and another 31 are self-contained but mutate one piece of server-global state (the magic test clock), which forces them to run alone.

	wdio6 tests/e2e	wdio7 tests/e2e-wdio7
Runnable specs	125	139
Magic-clock specs (serial only)	25	6
Depend on a previous spec	0	3
Parallel-safe	100 (80%)	130 (94%)

(Runnable = spec files minus UNIMPL placeholders, templates, shared -impl modules, and the permanently-skipped imp-exp-imp-exp-site.)

Why the number is so high — the isolation model

Every normal spec provisions its own site at runtime: it builds a site JSON and POSTs it to the test-mode import endpoint (server.importSiteData(...)), or drives the real create-site UI with a unique fake IP (utils.makeCreateSiteWithFakeIpUrl()) so the per-IP site-creation rate limiter never couples tests. Nothing relies on pre-seeded DB fixtures beyond the empty default site — the "previous conditions" each spec needs are created by the spec itself.

On top of that, wdio7 generates a unique local hostname per test worker unless a spec pins one (wdio.conf.ts, marker [052RKTL40]; utils/settings.ts → e2e-test-<timestamp>), explicitly "so they won't overwrite / try-to-use each other's sites". And no two specs pin the same fixed hostname — I checked for duplicate hostname literals both within each suite and across the two suites: none.

Blocker 1 — magic time (31 specs)

server.playTimeSeconds/Minutes/Hours/Days() fast-forwards the app server's one global test clock, so a concurrently running spec would see time jump: sessions expire, review-undo windows vanish, notification/digest timing skews. The runner already knows this — tyd runs the .mtime filename group with --not-parallel (s/impl/tyd-e2e-tests.ts:280).

• wdio6: 25 specs, and the marker is perfectly accurate — the 25 .mtime-named specs are exactly the 25 whose bodies call playTime* (moderation/review, drafts, notification emails, snooze, spam/akismet, summary emails, session expiry, edit history; ls tests/e2e/specs | grep mtime lists them all).
• wdio7: 6 specs, but only 2 are marked (admin-review-cascade-approval.2br.f.mtime, chat-basic.2br.f.mtime). The other 4 call adminArea.review.playTimePastUndo() without the marker — a latent race under --parallel N, reported separately as wdio7: four magic-time specs lack the .mtime marker, so --parallel can race the global test clock

Blocker 2 — the only true previous-conditions dependency (4 specs, wdio7)

embcom.expimpjson.create-site-exp-json exports a site dump to a fixed path on disk (c.EmbCommentsJsonExport). Then imp-to-new-site, restore-overwrite-site-new-domain, and restore-overwrite-site-same-domain each read that dump — the only genuine "depends on a previous test" cases in either suite. All three also write the same working copy (c.EmbCommentsJsonExportCopy), so they're mutually exclusive with each other too: exporter first, importers serialized among themselves — though the 4-spec group as a whole is independent of everything else. (wdio6's single-spec equivalent, imp-exp-imp-exp-site.test.ts, sits in tyd's permanent skip list.)

Parallel-safe, but with shared infrastructure or gating

• Embedded-comments specs (21 wdio6 / 36 wdio7) need the static file server on :8080 serving target/ — one shared read-only process, fine concurrently. The wdio6 gatsby spec runs twice against two different site builds on :8000; those two passes must not overlap each other.
• Webhook specs (wdio7: webhooks-retry, webhooks-enable-disable, webhooks-for-api-upserts, do-api-create-pages-comts-check-webhooks-search) share the fake receiver fakeweb :8090, but its state is namespaced per siteId → concurrent-safe once it's up.
• Third-party-IdP specs (13 wdio6 / ~7 wdio7, extidp / include3rdPartyDependentTests) self-skip unless real Gmail/Facebook/GitHub/LinkedIn/Azure credentials are configured; when enabled they log into shared external test accounts, so they should serialize per provider. Four of the wdio6 ones (akismet / safe-browsing spam tests) are also .mtime.

What the harness supports today

• wdio7: --parallel N / -p N → wdio maxInstances (default 1 = serial); tyd partitions the .mtime group off automatically.
• wdio6: no parallel machinery at all — one spec per wdio invocation, sequential. (Interestingly, s/run-e2e-tests.sh:88–95 sketches multi-instance partitioning — -e <every> -o <offset> with per-instance hostnames — so running several wdio6 runners against separate stacks was designed for, just never finished.)

Analyzed at the running commit, v1.2026.003.