JingsongLi commented on PR #941:
URL: https://github.com/apache/paimon-rust/pull/941#issuecomment-5936099344
The primary/fallback option guards work for ordinary branch names; all 35
existing procedure tests and 19 branch-manager tests passed.
**[P1] Validate each logical branch name before filesystem
existence/deletion** (`proc_delete_branch`,
`crates/integrations/datafusion/src/procedures.rs`, around lines 470–486). The
new procedure accepts `prod/schema` as a branch name. The guard compares it
literally against the configured `prod`, so it passes; `branch_exists` then
finds the real `branch-prod/schema` directory, and `drop_branch` recursively
deletes it. This bypasses the intended production-reader protection and
destroys the protected branch's schema metadata.
I reproduced this on the exact head: a native primary-key table with
`scan.primary-branch=prod`, one committed row, a tag and a readable `prod`
created from the tag. `CALL sys.delete_branch(table => 'test_db.t1', branch =>
'prod/schema')` succeeds; afterward a fresh `table.copy_with_branch("prod")`
fails. The regression reports `protected branch readable=false`. The core
directory primitive already existed, but this PR exposes the unchecked name
through SQL.
Please apply the existing catalog/table branch-name validation before
`branch_exists` or deletion (including separator/control-character rejection),
then check the configured branches. A temporary control using that validator
passes the real metadata-preservation probe for both primary and fallback
options. Normal deletion and sequential batch semantics otherwise match Java; I
am not requesting atomic batch deletion.
--
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]
