Gabriel39 commented on issue #66497: URL: https://github.com/apache/doris/issues/66497#issuecomment-5301637401
Thanks for the v5.1 revision. I read it against the full discussion history and the final Doris 4.2 scope clarification. I agree with the design overall: it preserves the accepted one-shot safety invariants, keeps the lifecycle compact, and correctly moves the broader reconciliation, REST, distributed, incremental, and query-architecture work out of the 4.2 release boundary. No further structural rewrite is needed. Please make only these two contained clarifications before proceeding: 1. **Restore the local/`file://` mutation restriction.** Earlier revisions correctly made local-path mutation disabled by default, allowed only under an explicit single-node/test operator assertion, and rejected it in multi-node deployments because identical path strings do not prove a shared filesystem namespace. V5.1 currently scopes mutation to Directory Catalog generally but no longer states this restriction. Please restore it and keep object storage as the production path. 2. **Remove the ambiguity around pre-invocation busy rejection.** Sections 5.1/5.3 require durable `RUNNING` before execute network I/O and prohibit redispatch once `RUNNING`, while Section 5.2 says a pre-invocation busy rejection leaves the job `PENDING` for another BE. Please make the boundary explicit: while `PENDING`, selection/reservation must be strictly non-invoking; once `RUNNING` is durable and the execute request is sent, a complete trusted pre-FFI rejection should become `NOT_COMMITTED` and must not be automatically redispatched. Alternatively, define a separate non-invoking reservation handshake and state clearly that it cannot enter FFI. With these two small corrections, the proposal matches the expected 4.2 boundary. Please go ahead with implementation after updating the design. -- 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]
