Fix handleTssMismatches crashes. [release-7.4]

[jzhou77]

cherrypick #12328

handleTssMismatches(DatabaseContext* cx) uses a pointer to DatabaseContext object, which can be destroyed when "tr" is reset within this actor. However, the actor can't be destroyed because it's on the stack. Introducing this delay gives a chance to cancel the actor.

20250826-165641-jzhou-a1cbfc05926fdfd9 compressed=True data_size=59276546 duration=4833332 ended=100000 fail=1 fail_fast=10 max_runs=100000 pass=99999 priority=100 remaining=0 runtime=1:22:44 sanity=False started=100000 stopped=20250826-181925 submitted=20250826-165641 timeout=5400 username=jzhou

Interestingly, the failure is -f ./tests/rare/ClogRemoteTLog.toml -s 870359747 -b off with ClogRemoteTLogCheckFailed Sev40, which is not the crashing failure this PR fixed.

Code-Reviewer Section

The general pull request guidelines can be found here.

Please check each of the following things and check all boxes before accepting a PR.

• The PR has a description, explaining both the problem and the solution.
• The description mentions which forms of testing were done and the testing seems reasonable.
• Every function/class/actor that was touched is reasonably well documented.

For Release-Branches

If this PR is made against a release-branch, please also check the following:

• This change/bugfix is a cherry-pick from the next younger branch (younger release-branch or main if this is the youngest branch)
• There is a good reason why this PR needs to go into a release branch and this reason is documented (either in the description above or in a linked GitHub issue)

[foundationdb-ci]

Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x

• Commit ID: f887890
• Duration 0:40: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]

Result of foundationdb-pr-clang-arm on Linux CentOS 7

• Commit ID: f887890
• Duration 0:48: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]

Result of foundationdb-pr-macos on macOS Ventura 13.x

• Commit ID: f887890
• Duration 1:02:52
• 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]

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

• Commit ID: f887890
• Duration 1:13:13
• 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]

Result of foundationdb-pr-clang on Linux RHEL 9

• Commit ID: f887890
• Duration 2:23:05
• 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]

Result of foundationdb-pr on Linux RHEL 9

• Commit ID: f887890
• Duration 2:23:15
• 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)

[gxglass]

Interesting. I wonder if there is a use for something like

#define CHECK_FOR_CANCELLATION wait(delay(0))

and call it at the top of loops that need this property? That said I don't know how frequent this need arises.

[jzhou77]

Interesting. I wonder if there is a use for something like

#define CHECK_FOR_CANCELLATION wait(delay(0))

and call it at the top of loops that need this property? That said I don't know how frequent this need arises.

That's a good idea. I think there are maybe 2 or 3 other places we used this trick before.