Defensive check error -4377 in check_old_row_legitimacy due to storage_val != sql_val

[hnwyllmm]

Environment

• Version: observer (OceanBase)
• Revision: 1-36bcfa8570e535e06871c9e84174fea4482cd1a2
• Build Branch: 4_2_x_release
• Build Time: Jul 14 2026 02:29:00
• Build Flags: RelWithDebInfo
• Build Info: obbuild-asan-4_2_x_release-102587

Description

During an UPDATE operation, a defensive check in check_old_row_legitimacy failed with error code -4377 (OB_ERR_DEFENSIVE_CHECK). The error indicates a mismatch between the value read from storage (storage_val) and the value expected by the SQL layer (sql_val).

The specific error from the log is:

storage_val is not equal with sql_val, maybe catch a bug(ret=-4377, storage_val={"BIGINT":630}, sql_val={"BIGINT":631}, cmp=-1, column_ids.at(i)=16)

This suggests the SQL layer expected column 16 to have a value of 631, but the storage layer read a value of 630 for the same column during an UPDATE operation, triggering a fatal internal error.

Steps to Reproduce

The error occurred while executing the following SQL statement:

UPDATE t1 SET name=CONCAT(name, @l:=@l+1);

Timestamp: 2026-07-16 01:57:31.101493 => 2026-07-16 01:57:31.338119
Error: 4377 - fatal internal error in [check_old_row_legitimacy]
Trace ID: YCB230BA2DA5D-000656A9EA0910A6-0-0
Warnings: 0
Changed: 0

Environment Information

• User: work
• Password: CB1TnKbEoOAqI2e8
• Sys Tenant Connection: obclient -h -P52004 -uroot@sys -A oceanbase
• 1004 Tenant Connection: obclient -h -P52004 -uroot@mysql -A
• SQL Execution Logs: /data/1/pquery_job10/master/backup/backup/myback.2026-07-/execlog
• Observer Logs: /data/1/pquery_job10/master/backup/backup/myback.2026-07-/pquery_job10.obs0/
• Binary: /data/1/pquery_job10/master/backup/backup/myback.2026-07-/observer

Log Information

Key error log lines:

[2026-07-16 01:57:31.332121] WDIAG [STORAGE] check_old_row_legitimacy (ob_ls_tablet_service.cpp:4061) [476847][T1004_L0_G0][T1004][YCB230BA2DA5D-000656A9EA0910A6-0-0] [lt=1][errcode=-4377] storage_val is not equal with sql_val, maybe catch a bug(ret=-4377, storage_val={"BIGINT":630}, sql_val={"BIGINT":631}, cmp=-1, column_ids.at(i)=16)

[2026-07-16 01:57:31.332686] WDIAG check_old_row_legitimacy (ob_ls_tablet_service.cpp:4102) [476847][T1004_L0_G0][T1004][YCB230BA2DA5D-000656A9EA0910A6-0-0] [lt=13][errcode=-4377] fatal internal error in [check_old_row_legitimacy]

[2026-07-16 01:57:31.332702] EDIAG [STORAGE] check_old_row_legitimacy (ob_ls_tablet_service.cpp:4112) [476847][T1004_L0_G0][T1004][YCB230BA2DA5D-000656A9EA0910A6-0-0] [lt=10][errcode=-4377] Fatal Error!!! Catch a defensive error!(ret=-4377, column_id=[1, 16, 17, 18], storage_old_row={row:[{"BIGINT UNSIGNED":32}, {"BIGINT":630}, {"NULL":"NULL"}, {"MYSQL_DATE":"2000-06-30"}], projector:null}, sql_old_row={row:[{"BIGINT UNSIGNED":32}, {"BIGINT":631}, {"VARCHAR":"631", collation:"utf8mb4_general_ci", coercibility:"INVALID"}, {"MYSQL_DATE":"2000-06-31"}], projector:null}, ...)

Additional diagnostic information shows the transaction was rolled back after the error, and the system attempted to locate the problematic row via single merge (returning error -4008).

Impact

This is a defensive check failure indicating potential data inconsistency or a bug in the storage layer. The UPDATE operation failed, and the transaction was rolled back. This could lead to application errors and data integrity concerns.

Additional Context

• Is this an RD-provided temporary version? No
• Reproducibility: Not specified
• Test changes: Not specified
• Other environmental abnormalities/changes: Not specified

[hnwyllmm]

Clone from 4_2_x_release by ob-task, source -> (You need to patch this commit to the master branch (the branch points to the lite mainline when cloned) GITLAB REVISION: