Skip to content

[CELEBORN-2483] Fix flaky RemoteShuffleMasterSuiteJ shuffleCount assertions racing with the initial app heartbeat - #3875

Open
afterincomparableyum wants to merge 1 commit into
apache:mainfrom
afterincomparableyum:flaky-remote-shuffle-master-heartbeat
Open

afterincomparableyum wants to merge 1 commit into
apache:mainfrom
afterincomparableyum:flaky-remote-shuffle-master-heartbeat

Conversation

@afterincomparableyum

@afterincomparableyum afterincomparableyum commented Oct 17, 2026 •

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

  • Add the internal conf celeborn.test.client.application.heartbeat.enabled (default true). When it is false, ApplicationHeartbeater does not schedule the app heartbeat.
  • Disable the app heartbeat in RemoteShuffleMasterSuiteJ, replacing the heartbeatInterval=1h workaround from CELEBORN-2431.

Why are the changes needed?

RemoteShuffleMasterSuiteJ.testRegisterPartitionWithProducer is still flaky after CELEBORN-2431:

RemoteShuffleMasterSuiteJ.testRegisterPartitionWithProducer:127 expected:<1> but was:<0>
RemoteShuffleMasterSuiteJ.testRegisterPartitionWithProducer:158 expected:<3> but was:<1>

ApplicationHeartbeater schedules its first heartbeat with an initial delay of 0. Each heartbeat drains LifecycleManager#shuffleCount and the fallback counts via sumThenReset. The LifecycleManager is created in registerJob, so the first heartbeat runs at the same time as the test's registerPartitionWithProducer calls and can reset the counter between an increment and its assertion. Raising the interval to 1h only removed the periodic heartbeats, not the initial one. The suite has no master, so no test in it needs the heartbeat. The production initial delay is unchanged.

Example failures: flink1 (11, 1.18), flink2 (17, 2.2).

Does this PR resolve a correctness bug?

  • Yes

Does this PR introduce any user-facing change?

  • Yes

How was this patch tested?

RemoteShuffleMasterSuiteJV120: 7 tests passed. The AskSync HeartbeatFromApplication failed errors, which appeared once per test in CI, should no longer appear.

…rtions racing with the initial app heartbeat

ApplicationHeartbeater schedules its first heartbeat with an initial delay of
0, and each heartbeat drains LifecycleManager#shuffleCount and the fallback
counts via sumThenReset. The LifecycleManager is created in registerJob, so
that first heartbeat runs concurrently with the test's
registerPartitionWithProducer calls and can reset the counter between an
increment and its assertion (expected:<1> but was:<0>, expected:<3> but
was:<1>). CELEBORN-2431 raised the heartbeat interval to 1h, which only
removed the periodic heartbeats, not the initial one.

Add the internal conf celeborn.test.client.application.heartbeat.enabled
(default true) and disable the app heartbeat in RemoteShuffleMasterSuiteJ,
which has no master to heartbeat to. The production initial delay is
unchanged.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant