[MINOR][CI] Raise federated request timeout for multitenant Spark tests#2505
Merged
Merged
Conversation
Set sysds.federated.timeout in the multi-tenant test config from 16s to 60s. The 16s bound was too aggressive for the Spark-backed (SP) variants of the federated multitenant reuse tests: Spark context creation alone takes ~14s, so under shared CI load a single federated request (both the rightIndex/rblk instruction execution and the end-of-run stats collection) routinely exceeded 16s and threw TimeoutException. These spurious timeouts caused FederatedReuseReadTest.testModifiedValLineageSP and FederatedSerializationReuseTest.testRowSumsSP to fail intermittently; surefire then reran each failing test, and the accumulated rerun time repeatedly pushed the monitoring/multitenant CI job past its 30-minute cap, cancelling the whole shard. 60s keeps a hard bound on a genuinely runaway request (so the suite still cannot hang silently) while giving the Spark variants enough headroom to complete on the first attempt, which also removes the expensive reruns.
Replace the verbose explanatory comment with the original one-line description; the rationale lives in the commit history.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2505 +/- ##
============================================
+ Coverage 71.45% 71.51% +0.06%
- Complexity 48864 48947 +83
============================================
Files 1573 1573
Lines 189239 189334 +95
Branches 37128 37149 +21
============================================
+ Hits 135215 135406 +191
+ Misses 43576 43456 -120
- Partials 10448 10472 +24 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
**.functions.federated.monitoring.**,**.functions.federated.multitenant.**CI shard has been intermittently failing and, when reruns pile up, timing out at the 30-minute job cap (e.g. run 28041416088).Root cause: the multi-tenant test config pins
sysds.federated.timeoutto 16s. This value bounds both federated instruction execution (FederationMap/FederatedData) and end-of-run stats collection (FederatedStatistics.collectFedStats). For the Spark-backed (*SP) variants of the reuse tests, Spark context creation alone is ~14s, so under shared CI load a single federated request regularly exceeds 16s and throwsTimeoutException:SPARK°rightIndex°… DMLRuntimeException -- java.util.concurrent.TimeoutExceptionException … thrown while getting the federated stats of the federated responseThe spurious timeouts make
FederatedReuseReadTest.testModifiedValLineageSPandFederatedSerializationReuseTest.testRowSumsSPfail; surefire then reruns each failing test, and the accumulated rerun time repeatedly pushes the shard past the 30-minute cap, cancelling the whole job.This bumps the timeout to 60s: still a hard bound on a genuinely runaway request (the suite cannot hang silently — the reason it was lowered from 128 → 16 in
8f5a42c0), but enough headroom for the Spark variants to pass on the first attempt, which also removes the expensive reruns and brings the shard comfortably back under the time cap.Evidence (recurring flake, last ~2 weeks)
Same two tests, same
TimeoutExceptionsignature, across independent runs:testModifiedValLineageSP,testRowSumsSPtestModifiedValLineageSPtestModifiedValLineageSP,testPlusScalarCP,testRowSumsSPtestModifiedValLineageSP, `testRow