WT-13948 Deprecate rollback_reason API

[LX6T]

After milestone 2 and WT-13947 all rollback reason messages should have been covered by the get_last_error API. This ticket involves deprecating the rollback reason API. In this case, we should be changing all existing rollback_reason related tests to use the get_last_error API.

[github-actions]

Thanks for creating a pull request! Please answer the questions below by editing this comment.

Type of change made in this PR

• Functional change
• Test-only change
• Refactor-only change
• Other non-functional change

What makes this change safe?

Answering this question helps the reviewers understand where they should focus their attention. Please consider these prompts:

• How risky is this change? Why?
  Medium risk, as the change touches many areas of the code I'm not familiar with and also have low code coverage, as well as altering various APIs relied upon by the server.

• What tests are you adding, changing or relying on? Why?
  Deprecating rollback_reason involved removing the python test file (test_txn27.py) associated with it, and altering the format test snap.c to instead use the session's err_info struct.

• What, if anything, are you concerned about that you'd like the reviewer to focus on?
  See if there are any mentions of rollback_reason that I've missed, and check all the replacements with get_last_error/err_info are appropriate.

References:

• Risk level guide
• Testing frameworks

Checklist before requesting a review

• I have performed a self-review of my code.
• I have made corresponding changes to the documentation, or no documentation change is needed.
• I have tests that show my change is correct, or have described above why functional test changes are not required.

[wiredtiger-prbot]

Test coverage is very low, please refer to the Code change/coverage report links below and try to improve it if feasible.

Metric (for added/changed code)	Coverage
Line coverage	64% (7/11)
Branch coverage	50% (6/12)

• Code change report
• Code coverage report (catch2)
• Code coverage report (full)

⚠️ This PR touches methods that have an extremely high complexity score!

• In src/evict/evict_lru.c the complexity of __wti_evict_app_assist_worker has increased by 2 to 34.

[LX6T]

Running a full patch build to check that nothing else relies on rollback_reason

[jiechenbo]

I wouldn't deem this as high risk, maybe medium risk. High risk would refer to no testing can be done to ensure this is correct.

[jiechenbo]

Nice go at the deprecation, have a few comments

[DylanSHLiang]

LGTM!

[etienneptl]

LGTM!

[jiechenbo]

Have two comments, can you also do a full wiredtiger patch build and once MongoDB has removed the usage of rollback_reason to also do a full MongoDB patch build?

[jiechenbo]

is this test still valuable to have? Maybe its worth placing it under a error_info.py test

[LX6T]

I don't think there's anything in there that isn't covered by test_error_info02.py, I can double check with @DylanSHLiang.

[LX6T]

I just checked, he says nothing of value will be lost.

[jiechenbo]

I would rather keep it cause its a completed written test, there is no harm in having potential extra coverage.

[LX6T]

Restored in Restored the test_rollback_reason python test, using the get_last_err….

[LX6T]

Hi @lukech, for context we thought it'd be worth adding you as a reviewer to this PR since it involves deprecating a feature that could potentially have wider consequences for Mongo or any other customers currently relying on it.
The rollback_reason API is currently also being removed from Mongo by the RSS team, so once that's done we want to make sure it's safe to be removed from WT. Do you know of any other places the API needs to be removed from, or any reasons that this change might be problematic?

[lukech]

@LX6T thanks for the useful context. I'm not aware of any application/customer other than Mongo server that makes use of this rollback reason API. Just to confirm you won't merge this PR until after Mongo Server removes the usage of this API, right? Normally, API interface changes need to update the dist/api_data.py file and corresponding documentation. I'm guessing this rollback reason removal change won't affect the public API interface but rather impact the internal structure. Please confirm. Testing wise, I'd suggest running a full WT patch build and a mongo server patch build to make sure no breakage before merge.

[LX6T]

@LX6T thanks for the useful context. I'm not aware of any application/customer other than Mongo server that makes use of this rollback reason API. Just to confirm you won't merge this PR until after Mongo Server removes the usage of this API, right? Normally, API interface changes need to update the dist/api_data.py file and corresponding documentation. I'm guessing this rollback reason removal change won't affect the public API interface but rather impact the internal structure. Please confirm. Testing wise, I'd suggest running a full WT patch build and a mongo server patch build to make sure no breakage before merge.

Thanks for the response @lukech, I can confirm that we won't merge this until get_rollback_reason is fully removed from Mongo, and it isn't mentioned in api_data.py so there's nothing to update there. The only documentation change is in wiredtiger.in, I'm pretty sure that's the only place it's mentioned. And I'll definitely run some full patch builds once the Mongo side is all done.