Skip to content

feat(fs): expose isLocked in stat() to surface path-lock state#1940

Merged
qin-ctx merged 1 commit intovolcengine:mainfrom
fengluodb:feat/fs-stat-is-locked
May 9, 2026
Merged

feat(fs): expose isLocked in stat() to surface path-lock state#1940
qin-ctx merged 1 commit intovolcengine:mainfrom
fengluodb:feat/fs-stat-is-locked

Conversation

@fengluodb
Copy link
Copy Markdown
Collaborator

Adds an isLocked boolean to the dict returned by VikingFS.stat() so callers (and the /api/v1/fs/stat endpoint, which transparently passes the dict through) can tell whether a resource is currently held by a path lock without having to attempt a write and observe ResourceBusyError.

The lookup reuses the same conflict-detection semantics as the acquire flow: a path is reported as locked when it has a valid .path.ovlock or when any ancestor directory holds a SUBTREE lock; stale locks are ignored because the next acquirer would reclaim them anyway.

To make the check available to higher layers, a public PathLock.is_locked() helper is introduced and surfaced through LockManager.is_path_locked(); both are best-effort and degrade to False when the LockManager is unavailable, keeping stat() resilient.

Description

Related Issue

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Refactoring (no functional changes)
  • Performance improvement
  • Test update

Changes Made

Testing

  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I have tested this on the following platforms:
    • Linux
    • macOS
    • Windows

Checklist

  • My code follows the project's coding style
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • Any dependent changes have been merged and published

Screenshots (if applicable)

Additional Notes

Adds an `isLocked` boolean to the dict returned by `VikingFS.stat()` so
callers (and the `/api/v1/fs/stat` endpoint, which transparently passes
the dict through) can tell whether a resource is currently held by a
path lock without having to attempt a write and observe `ResourceBusyError`.

The lookup reuses the same conflict-detection semantics as the acquire
flow: a path is reported as locked when it has a valid `.path.ovlock` or
when any ancestor directory holds a SUBTREE lock; stale locks are
ignored because the next acquirer would reclaim them anyway.

To make the check available to higher layers, a public
`PathLock.is_locked()` helper is introduced and surfaced through
`LockManager.is_path_locked()`; both are best-effort and degrade to
`False` when the LockManager is unavailable, keeping `stat()` resilient.
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 9, 2026

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪
🏅 Score: 90
🧪 PR contains tests
🔒 No security concerns identified
✅ No TODO sections
🔀 No multiple PR themes
⚡ Recommended focus areas for review

Missing Logging

The _is_path_locked helper uses a broad except Exception without logging. This could hide unexpected errors during lock lookup, making debugging harder.

except Exception:
    return False

@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 9, 2026

PR Code Suggestions ✨

No code suggestions found for the PR.

@qin-ctx qin-ctx merged commit 6d533f9 into volcengine:main May 9, 2026
5 checks passed
@github-project-automation github-project-automation Bot moved this from Backlog to Done in OpenViking project May 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants