[Bug] table_streams still shows dropped base table name after base table is dropped

[MoanasDaddyXu]

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!

[zclllyybb]

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:

• The BE SchemaTableStreamsScanner only requests TABLE_STREAMS rows from FE and copies the returned TRow values into the result block. It does not decide the base-table fields.
• FE builds these rows in TableStreamManager.fillTableStreamValuesMetadataResult(). That method emits N/A for BASE_TABLE_NAME, BASE_TABLE_DB, BASE_TABLE_CTL, and BASE_TABLE_TYPE only when stream.getBaseTableNullable() returns null; otherwise it emits the cached base table qualifiers.
• BaseTableStream keeps a volatile cached baseTable reference created with the stream. getBaseTableNullable() only resolves through StreamTableInfo when that cache is already null.
• The base-table drop path unregisters and recycles the dropped table, and Database.unregisterTable() marks the dropped table object as dropped. However, dropping the base table does not clear the stream's cached baseTable reference and does not remove the stream from TableStreamManager; 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_streams then sees a non-null base table and prints base_drop, which matches the reported assertion failure. The existing code already has a dropped-table check in the partition-offset cleanup path, but the table_streams metadata row builder does not apply an equivalent unavailable-table check.

Recommended next step:

• Fix the FE metadata/lifecycle handling so a dropped or no-longer-resolvable base table is treated as unavailable for stream metadata. The most local fix is around TableStreamManager.fillTableStreamValuesMetadataResult() / BaseTableStream.getBaseTableNullable(): do not use cached qualifiers when the cached table is dropped, and return N/A for 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.
• Please make the intended stale semantics explicit in the fix: if a dropped base table means the stream is stale, IS_STALE and STALE_REASON should be updated consistently, not only the displayed BASE_TABLE_* columns.
• Add a regression case for the live-runtime path: create base table, create stream, drop base table with FORCE, then query information_schema.table_streams before 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:

• The full information_schema.table_streams row from the failing run, especially BASE_TABLE_CTL, BASE_TABLE_TYPE, IS_STALE, and STALE_REASON.
• FE logs around CREATE STREAM, DROP TABLE base_drop FORCE, and the following information_schema.table_streams query.
• Whether the expected behavior is only display-level N/A, or whether the stream should also become stale/disabled after its base table is dropped.
• The exact public commit/branch if d4a077caf8a is not reachable from the public upstream remote; I inspected the same table-stream metadata path on current reachable upstream/master.