zclllyybb commented on issue #65389: URL: https://github.com/apache/doris/issues/65389#issuecomment-4915017598
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
