-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Minor - P4
-
Affects Version/s: None
-
Component/s: Transactions
-
None
-
Environment:GCC 13, Ubuntu 24.04
-
Storage Engines - Transactions
-
581.595
-
None
-
1
In src/txn/txn.c __wt_txn_config (line 677), operation_timeout_us is set when operation_timeout_ms is parsed via __txn_conf_operation_timeout. If a subsequent configuration step fails (such as read_timestamp parsing at lines 748-751), control jumps to the err: label (line 754). This jump bypasses the cleanup of txn->operation_timeout_us, leaving the timeout value stuck. Consequently, the next successful begin_transaction call on the same session inherits the stale timeout, causing unexpected operation timeouts.
For Reproduce;
The catch2 unit test test_txn_config.cpp reproduces the bug and verifies the fix (I attached the before/after outputs on JIRA).
Without the fix, the reproducer leaves txn->operation_timeout_us set to the value requested via operation_timeout_ms=100 (i.e. 100000 µs) after the failed begin_transaction, and a subsequent successful begin_transaction inherits that stale timeout.
With the fix, operation_timeout_us is correctly reset to 0 on the error path.
Proposed Fix;
Adding cleanup under the err: label of __wt_txn_config(). When ret is non-zero, reset txn->operation_timeout_us to 0, consistent with the existing cleanup of txn->flags and txn->time_point.flags.