…726)
A REMOVE staging operation deletes a remote resource and never touches
the local filesystem, yet _handle_staging_operation raised a
ProgrammingError demanding staging_allowed_local_path before dispatching
to any handler. This forced callers to pass a dummy path (e.g. "/") just
to run a REMOVE, even though the value is never used.
Handle REMOVE before the staging_allowed_local_path validation block,
mirroring how the __input_stream__ PUT path already bypasses it. GET and
local-file PUT continue to require staging_allowed_local_path.
Closes #726
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
Summary
Fixes #726.
A REMOVE staging operation deletes a remote resource and never touches the local filesystem, yet Cursor._handle_staging_operation raised:
before dispatching to any handler when staging_allowed_local_path was None. This forced callers to pass a dummy path (e.g. "/") just to run a REMOVE, even though the value is never used for that operation — the reporter observed they could PUT via __input_stream__ without a path, but REMOVE still demanded one.
Root cause
In src/databricks/sql/client.py, _handle_staging_operation validated staging_allowed_local_path for every non-streaming operation before dispatch. The REMOVE branch then explicitly popped local_file because "Local file isn't needed to remove a remote resource" — confirming the requirement was spurious for REMOVE.
Fix
Handle REMOVE early, right after the existing __input_stream__ PUT bypass and before the staging_allowed_local_path validation block. GET and local-file PUT continue to require staging_allowed_local_path.
Test plan
Added tests/unit/test_staging_remove.py:
Verification:
Added a CHANGELOG entry under a new Unreleased section.
Closes #726