Fix hang when executing call dbms_vector.refresh_index

Description

After executing DDL tasks, calling the SQL statement call dbms_vector.refresh_index("VECTOR_IDX", "C", "col_varchar_200", 0) causes the session to hang indefinitely.

Steps to Reproduce

1. Connect to the database using the provided connection string: mysql -h -P50227 -uroot
2. Execute the DDL tasks (specific tasks not detailed in original report).
3. Execute the following SQL statement:

   call dbms_vector.refresh_index("VECTOR_IDX", "C", "col_varchar_200", 0)
   

4. The session becomes unresponsive (hangs).

Observed State:
A query on oceanbase.__all_virtual_processlist shows the session in an 'ACTIVE' state for a prolonged period with the top_info field showing the hanging call.

SELECT time,top_info,db FROM oceanbase.__all_virtual_processlist WHERE state = 'ACTIVE' order by time desc limit 1
*************************** 1. row ***************************
    time: 33888.308555
top_info: call dbms_vector.refresh_index("VECTOR_IDX", "C", "col_varchar_200", 0)
      db: vector_db_rqg_heap

Environment

Note: Specific version details were not provided in the required fields of the original report. The following environment information was extracted from the context:

• Log Directory: /obdata/data/vec/hybrid_vector_index/work_path/obm.z1.obs0/log
• Connection String: mysql -h -P50227 -uroot
• Database: vector_db_rqg_heap

Additional Fields from Original Template (Not Filled):

• Version Information (Required): Not provided.
• Is it an RD-provided temporary version: Not provided.
• Reproducibility Difficulty: Not provided.
• Test Change Details: Not provided.
• Other Environment Anomalies/Changes: Not provided.
• Environment Info (Tenant connection strings, deployment info): Not provided.
• Whether the scene was preserved: Not provided.

Log Information

The observer logs show repeated failures of check replica readable for the transaction associated with the hanging SQL (Trace ID: YB427F000001-0006519517F27D6A-0-0). The logs are extensive, showing this check failing continuously over time.

Sample Log Snippet:

seekdb.log.20260512192102869:[2026-05-12 19:19:57.959997] INFO  [STORAGE.TRANS] check_ls_readable_ (ob_trans_service_v4.cpp:1401) [612935][T1_L0_G0][T1][YB427F000001-0006519517F27D6A-0-0] [lt=36] check replica readable fail(ret=0, snapshot={val:1778584797809500000, v:0})
... (repeated many times)

Key Log Observations:

• The thread [612935][T1_L0_G0][T1] with trace ID YB427F000001-0006519517F27D6A-0-0 is repeatedly executing check_ls_readable_ and failing with ret=0.
• The associated SQL NIO session (session_id: 3221492913) shows sql_handling_stage:11 and remains active.
• Logs indicate activity related to tablet status checks (tablet_id: {id:546}) and I/O operations during the hang period.

Impact

The dbms_vector.refresh_index operation hangs, preventing vector index maintenance and potentially blocking related DDL/DML operations on the affected session. This impacts the usability of vector functionality.

Start with the repeated check_ls_readable_ failures in ob_trans_service_v4.cpp and correlate trace ID YB427F000001-0006519517F27D6A-0-0 with the dbms_vector.refresh_index call. Reproduce using the supplied mysql connection and SQL statement, then inspect the observer logs and process list; done means the call no longer hangs and the session completes normally.