perf(test): remove real-time waits and per-iteration content types in slow ITs (#36912)

[wezell]

Proposed Changes

Fixes three of the slowest integration-test hotspots identified from per-class CI timing analysis (run 31054926456). ~4.5 min of aggregate IT time recovered, all behavior-preserving:

Test	Before	Fix
StartEndScheduledExperimentsJobTest.testJob	124s — Thread.sleep(2 * 60 * 1000)	Scheduling windows compressed to 10/20 seconds (validateScheduling allows any date after now-1min); sleep 25s
JobQueueManagerAPIIntegrationTest abandoned-job tests	~100s — jobs inserted 5 min stale but tests wait for the detector's minute-granularity timer tick	AbandonedJobDetector.detectAbandonedJobs() made public; tests trigger the scan directly, latch 3min → 30s
TagAPITest.findTopTags…	78s — getWikiLikeContentType() inside a 100-iteration loop creates ~100 content types → ~100 ES update_mapping calls	Content type hoisted out of the loop (one instead of ~100)

The TagAPITest fix also stops that test permanently bloating the shared index mapping (ES mappings are append-only), which taxes every update_mapping from tests that run after it in MainSuite2b.

Only production change is a method visibility change (private → public) on AbandonedJobDetector.detectAbandonedJobs() — no logic touched; the scheduled executor calls the same method.

Investigated and deferred: ShortyIdApiTest.test404CacheWhenDBDown (76s) — not a simple timeout knob (pool is 60 conns / 3s checkout); needs profiling.

Related: #36910 / #36911 (suite reordering).

Checklist

• Tests (existing tests exercise all changed paths; timing-only changes)
• Translations
• Security Implications Contemplated (no security impact)

🤖 Generated with Claude Code

This PR fixes: #36912

This PR fixes: #36912

[claude]

Claude finished @wezell's task in 3m 32s —— View job

---

Code Review

• Read the full diff (origin/main...HEAD)
• Verified AbandonedJobDetector visibility change and test trigger semantics
• Verified experiments-job Awaitility rewrite for idempotency
• Verified TagAPITest content-type hoist

New Issues

No issues found.

Notes (non-blocking)

AbandonedJobDetector.detectAbandonedJobs() private → public — Correct and minimal. The method is idempotent (the while loop drains all abandoned jobs each call) and is the same method the scheduled executor invokes, so triggering it directly from a test can't diverge from production behavior. The threshold is set to 2 min in @BeforeAll (line 78) and the job is inserted at now-5min (line 493/606), so the direct scan finds it immediately — the latch reduction 3min → 30s is safe. The watchJob → ABANDONED state is set synchronously inside the scan, so the latch will fire well within 30s.

StartEndScheduledExperimentsJobTest — The Awaitility.untilAsserted rewrite is actually more robust than the old fixed Thread.sleep(2*60*1000): it re-runs the job (as Quartz would) and completes as soon as both absolute dates (now+10s, now+20s) pass, with the 2-min cap reserved for the failure path. Re-running the job is idempotent — the start experiment has no end date so it stays RUNNING across polls; the end experiment stays ENDED. No new flakiness introduced.

TagAPITest — Hoisting getWikiLikeContentType() out of the 100-iteration loop is behavior-preserving: the loop only ever used contentType.id() and all 100 contentlets can share one type. Cuts ~100 ES update_mapping calls to 1 and stops permanently bloating the shared MainSuite2b index mapping. Good catch on the append-only mapping side effect.

The lone production change (visibility only, no logic) is well-documented in the Javadoc. Approving-quality change.
· issue-36912-slow-it-waits

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request