Hi Yuxia and Fluss community, Thanks for sharing FIP-25. It is a very interesting proposal. While reading it and comparing it with the current `apache/main` branch, I had a few questions that may be worth clarifying.
First, the proposal says that `CALL sys.enable_fluss_on_lake_table(...)` waits for the `load_lake_data_to_fluss` Bulk Load job, snapshot registration, and datalake enablement to complete before returning. For a large Paimon table, this operation could take a considerable amount of time. Depending on the SQL Gateway, client, or HTTP/proxy configuration, the caller might time out while the underlying operation is still running. In that situation, it may be difficult for the caller to determine the final outcome. Would it make sense for the procedure to return a promotion operation ID and provide a separate way to query its status? Alternatively, it would be helpful to document how timeout and cancellation are expected to work. Second, I was wondering about failure recovery and retry behavior. If Fluss table creation succeeds but the Bulk Load job fails, the proposal says that the table remains present with datalake disabled. On a subsequent call, however, the existing table may cause the procedure to skip table creation and Bulk Load. It would be useful to clarify how the procedure can distinguish a successfully initialized table from one whose Bulk Load failed or is still incomplete. Could the design consider persisting some information such as the following to make retry and recovery easier to understand? - promotion operation ID; - source Paimon snapshot ID; - selected partitions; - Bulk Load transaction ID. It may also be helpful to describe the expected retry, abort, timeout, and cancellation semantics, and to make sure that a retry cannot enable datalake before the Bulk Load result has been successfully verified. Best regards, Liting Liu From: yuxia <[email protected]> Date: Tuesday, September 8, 2026 at 15:23 To: dev <[email protected]> Subject: [DISCUSS] FIP-25: Support In-Place Promotion of Existing Paimon Tables to Datalake-Enabled Fluss Tables Hi Fluss community, I'd like to start a discussion on FIP-25: Support In-Place Promotion of Existing Paimon Tables to Datalake-Enabled Fluss Tables[1]. This FIP proposes promoting an existing Paimon table to a datalake-enabled Fluss table in place through: CALL sys.enable_fluss_on_lake_table(...); "In-place" means reusing the existing Paimon table and historical data without creating a replacement table or rewriting the data to Paimon. Fluss creates the corresponding metadata, initializes historical primary-key state through Bulk Load when necessary, and validates schema and snapshot consistency before enabling datalake. Feedback and suggestions are welcome. [1]: https://cwiki.apache.org/confluence/spaces/FLUSS/pages/406623572/FIP-25+Support+In-Place+Promotion+of+Existing+Paimon+Tables+to+Datalake-Enabled+Fluss+Tables Best regards, Yuxia
