Neo4j.ClientError.TransientError.TransactionDeadlockDetected during rolling upgrade of causal cluster

Goal: achieve a seamless version upgrade of a three‑node Neo4j causal cluster without noticeable downtime for a small write‑heavy application.

Constraint: during a rolling upgrade old and new nodes run different protocol versions, which can increase lock‑contention and trigger the transient TransactionDeadlockDetected error; the application must distinguish this from permanent failures and decide whether built‑in driver retries are sufficient or if additional steps such as a store‑file clone and cut‑over are required.

Uncertainty: whether monitoring dbms.transaction.lock.wait.time and configuring exponential back‑off retries guarantees zero observable errors, or if a brief traffic switch is unavoidable to avoid mixed‑version lock conflicts.

Questions:

• What retry configuration (max attempts, back‑off strategy) for the Neo4j driver ensures that TransactionDeadlockDetected is handled without user‑visible latency?
• Is it sufficient to rely solely on driver retries and lock‑wait monitoring, or does a store‑file clone with load‑balancer cut‑over provide a stronger guarantee of zero errors?
• What threshold for sustained increase in lock‑wait time should trigger a pause in the rolling upgrade to prevent error accumulation?