Issue with Incomplete Rollback in PolarDB During Batch Write Operations

I'm encountering an unusual scenario while working with PolarDB where a batch of write SQL operations was executed. One of the SQL statements within this batch encountered an error, necessitating a transaction rollback. However, it appears that the rollback process did not complete successfully, even though no error messages were propagated back to the business logic layer, which typically monitors for such exceptions. Given that resource availability is not a concern — with ample CPU, memory, and sufficient free disk space — and there were no evident lock conflicts during this operation, I'm seeking guidance on how best to diagnose and understand why the rollback might have failed or appeared incomplete. Specifically, I'm interested in: 1. Diagnostic Steps: What are the recommended steps or tools to trace and verify the status of a rollback operation in PolarDB? 2. Error Logging: How can I ensure or check if any internal error logs within PolarDB might have captured details about the unsuccessful rollback attempt, given the absence of error reports in the application layer? 3. Transaction Isolation Levels: Could the transaction isolation level in use have any implications on the observed behavior, and if so, what adjustments might be considered? 4. Best Practices: Are there any known issues or best practices when handling transaction rollbacks in PolarDB, especially in the context of batched writes, that could help prevent or troubleshoot similar incidents? Any insights, past experiences, or pointers to relevant documentation would be greatly appreciated.