IGNITE-28675 Fix flaky TxDeadlockCauseTest #testCause, #testCauseSeveralNodes

[zstan]

No description provided.

[zstan]

From documentation:
https://ignite.apache.org/docs/ignite2/latest/key-value-api/transactions
However, if a deadlock is detected, the cause of the returned TransactionTimeoutException will be TransactionDeadlockException (at least for one transaction involved in the deadlock).

[sonarqubecloud]

Quality Gate failed

Failed conditions
4 New Code Smells (required ≤ 1)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[zstan]

https://tcbot2.sbt-ignite-dev.ru/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/13136/head&action=Latest

[ignitetcbot]

TCBot Test Analysis

• TeamCity: --> Run :: All Results
• Branch: pull/13136/head
• Base: master
• Tested commit: 94b11ec

Possible Blockers (0)

No blockers found.

New Tests (0)

No new tests found.

[ignitetcbot]

Thanks for working on this flaky test. I have two small suggestions:

1. Please reconsider making TxDeadlockDetection.deadLockTimeout static final while TxDeadlockDetectionNoHangsTest relies on @WithSystemProperty. In the suite, earlier tests can initialize TxDeadlockDetection before the class-level property is applied, so this test may still use the default timeout. A safer option is to read IGNITE_TX_DEADLOCK_DETECTION_TIMEOUT when creating the timeout object, or keep an explicit test hook. See TxDeadlockDetection, TxDeadlockDetectionNoHangsTest, and suite order in TxDeadlockDetectionTestSuite.

2. In TxDeadlockCauseTest, the new catch stores only exceptions that already have TransactionDeadlockException. If both transaction threads fail for another reason, the test will lose the original failure and report only assertNotNull. Could we keep the first non-deadlock exception as a diagnostic fallback, but still prefer the deadlock exception when it appears? See checkCauseObject.