Skip to content

[release-7.4] Fix an old exclude failed bug - #13869

Open
spraza wants to merge 2 commits into
apple:release-7.4from
spraza:port-7.4-pr13645
Open

[release-7.4] Fix an old exclude failed bug#13869
spraza wants to merge 2 commits into
apple:release-7.4from
spraza:port-7.4-pr13645

Conversation

@spraza

@spraza spraza commented Aug 14, 2026

Copy link
Copy Markdown
Collaborator

Port #13645 to release-7.4.

Problem: In removeKeysFromFailedServer, the writes that unassign a dropped shard from the dest servers (serverKeysFalse) and the writes that reassign it to the new team as an empty range were pushed into a single actors vector and awaited together. krmSetRangeCoalescing performs a read-modify-write on the serverKeys map, so when a server appears in both the dest set and the new team, running the two batches concurrently lets the coalescing reads observe stale state and produce an incorrect serverKeys assignment.

Solution: await the unassign batch first, then run the empty-range assignment in a separate batch, ensuring the serverKey map assignment is correct.

Same fix already backported to release-7.3 in #13662. release-7.4 still used the wait()/actor-compiler style rather than main's co_await, and shardId needed to become state since it now crosses the new wait() boundary -- same conflict resolution as the 7.3 backport.

100K: 20260813-171407-praza-port-7.4-pr13645-817f-e3951c728b485de6 pass=100000 fail=0 ended=100000 max_runs=100000

In removeKeysFromFailedServer, the writes that unassign a dropped shard
from the dest servers (serverKeysFalse) and the writes that reassign it
to the new team as an empty range were pushed into a single actors vector
and awaited together. krmSetRangeCoalescing performs a read-modify-write
on the serverKeys map, so when a server appears in both the dest set and
the new team, running the two batches concurrently lets the coalescing
reads observe stale state and produce an incorrect serverKeys assignment.

Await the unassign batch first, then run the empty-range assignment in a
separate batch, ensuring the serverKey map assignment is correct.

Ported from upstream/main PR apple#13645 (8bd7e44).
Conflicts resolved in: fdbserver/MoveKeys.actor.cpp (release-7.4 still uses
the wait()/actor-compiler style rather than main's co_await; shardId needed
to become state since it now crosses the new wait() boundary). Same
resolution as the release-7.3 backport, PR apple#13662.
@spraza
spraza marked this pull request as ready for review August 14, 2026 17:05
@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@spraza spraza closed this Aug 14, 2026
@spraza spraza reopened this Aug 14, 2026
@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-clang-arm on Linux RHEL 9

  • Commit ID: 17f7513
  • Duration 0:46:06
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-macos-m1 on macOS 14.x

  • Commit ID: 17f7513
  • Duration 0:48:56
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-clang on Linux RHEL 9

  • Commit ID: 17f7513
  • Duration 0:55:29
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr on Linux RHEL 9

  • Commit ID: 17f7513
  • Duration 0:58:27
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

This comment has been minimized.

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-cluster-tests on Linux RHEL 9

  • Commit ID: 17f7513
  • Duration 1:26:10
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)
  • Cluster Test Logs zip file of the test logs (available for 30 days)

@foundationdb-ci

Copy link
Copy Markdown
Contributor

Result of foundationdb-pr-macos on macOS 14.x

  • Commit ID: 17f7513
  • Duration 4:37:19
  • Result: ✅ SUCCEEDED
  • Error: N/A
  • Build Log terminal output (available for 30 days)
  • Build Workspace zip file of the working directory (available for 30 days)

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants