Repository navigation
[Bug](High) table_streams still shows dropped base table name after base table is dropped #65389
Description
Search before asking
- I had searched in the issues and found no similar issues.
Version
Reproduced with the table stream regression case on local Doris HEAD d4a077caf8a.
Test environment:
regression-test/suites/table_stream_p0/test_table_stream_base_table_unavailable.groovy
remote log: /mnt/disk1/jianxu/case_output/doris/testrun/table_stream_p0_20260708/test_table_stream_base_table_unavailable.retry2.log
FE: 172.20.49.4:9030
What's Wrong?
After a stream is created on a base table, dropping the base table does not make information_schema.table_streams report the base table as unavailable.
The regression case expects the stream to remain listed while the base table columns are reported as N/A. However, BASE_TABLE_NAME still returns the dropped table name.
Actual assertion:
expected: <N/A> but was: <base_drop>
What You Expected?
After dropping the base table, information_schema.table_streams should reflect that the stream's base table is unavailable, for example:
BASE_TABLE_NAME = N/A
BASE_TABLE_DB = N/A
How to Reproduce?
Regression case:
regression-test/suites/table_stream_p0/test_table_stream_base_table_unavailable.groovy
Minimal flow:
CREATE TABLE base_drop (
k1 INT,
v1 INT
)
DUPLICATE KEY(k1)
DISTRIBUTED BY HASH(k1) BUCKETS 1
PROPERTIES (
"replication_num" = "1",
"binlog.enable" = "true",
"binlog.format" = "ROW"
);
CREATE STREAM s_drop ON TABLE base_drop
PROPERTIES ("type" = "append_only");
DROP TABLE base_drop FORCE;
SELECT BASE_TABLE_NAME, BASE_TABLE_DB, BASE_TABLE_CTL, BASE_TABLE_TYPE,
IS_STALE, STALE_REASON
FROM information_schema.table_streams
WHERE DB_NAME = 'test_table_stream_base_unavail_db'
AND STREAM_NAME = 's_drop';Regression Test Result
suite: test_table_stream_base_table_unavailable
expected BASE_TABLE_NAME: N/A
actual BASE_TABLE_NAME: base_drop
Log excerpt:
Execute sql: DROP TABLE base_drop FORCE
Execute sql:
select BASE_TABLE_NAME, BASE_TABLE_DB, BASE_TABLE_CTL, BASE_TABLE_TYPE,
IS_STALE, STALE_REASON
from information_schema.table_streams
where DB_NAME = 'test_table_stream_base_unavail_db' and STREAM_NAME = 's_drop'
org.opentest4j.AssertionFailedError: expected: <N/A> but was: <base_drop>
Anything Else?
Tracking issue: #65265
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Activity
zclllyybb commentedon Jul 8, 2026
Breakwater-GitHub-Analysis-Slot: slot_954e705100d6
This content is generated by AI for reference only.
Initial assessment: this looks like a real FE metadata bug in the table-stream information schema path, not a BE schema-scanner issue.
Evidence from the current reachable upstream code path:
SchemaTableStreamsScanneronly requestsTABLE_STREAMSrows from FE and copies the returnedTRowvalues into the result block. It does not decide the base-table fields.TableStreamManager.fillTableStreamValuesMetadataResult(). That method emitsN/AforBASE_TABLE_NAME,BASE_TABLE_DB,BASE_TABLE_CTL, andBASE_TABLE_TYPEonly whenstream.getBaseTableNullable()returnsnull; otherwise it emits the cached base table qualifiers.BaseTableStreamkeeps a volatile cachedbaseTablereference created with the stream.getBaseTableNullable()only resolves throughStreamTableInfowhen that cache is alreadynull.Database.unregisterTable()marks the dropped table object as dropped. However, dropping the base table does not clear the stream's cachedbaseTablereference and does not remove the stream fromTableStreamManager;removeTableStream()is only called when the dropped object itself is a stream.So after
DROP TABLE base_drop FORCE, the stream can still hold a non-null Java reference to the old dropped table object.information_schema.table_streamsthen sees a non-null base table and printsbase_drop, which matches the reported assertion failure. The existing code already has a dropped-table check in the partition-offset cleanup path, but thetable_streamsmetadata row builder does not apply an equivalent unavailable-table check.Recommended next step:
TableStreamManager.fillTableStreamValuesMetadataResult()/BaseTableStream.getBaseTableNullable(): do not use cached qualifiers when the cached table is dropped, and returnN/Afor the base-table columns. A broader lifecycle fix could also mark the dependent stream stale and clear/invalidate the cached base-table reference when the base table is dropped.IS_STALEandSTALE_REASONshould be updated consistently, not only the displayedBASE_TABLE_*columns.FORCE, then queryinformation_schema.table_streamsbefore any FE restart and assert the base-table fields and stale fields. This case is important because the failure is caused by an in-memory cached reference.Missing information that would help confirm the exact expected behavior:
information_schema.table_streamsrow from the failing run, especiallyBASE_TABLE_CTL,BASE_TABLE_TYPE,IS_STALE, andSTALE_REASON.CREATE STREAM,DROP TABLE base_drop FORCE, and the followinginformation_schema.table_streamsquery.N/A, or whether the stream should also become stale/disabled after its base table is dropped.d4a077caf8ais not reachable from the public upstream remote; I inspected the same table-stream metadata path on current reachable upstream/master.[-][Bug] table_streams still shows dropped base table name after base table is dropped[/-][+][Bug](High) table_streams still shows dropped base table name after base table is dropped[/+]TsukiokaKogane commentedon Sep 9, 2026
fixed in #67173