BloopAI/vibe-kanban · error

Scratch path should be valid

Error message

Scratch path should be valid

What it means

This panic comes from an `.expect()` in `Patch::add` (crates/services/src/services/events/patches.rs:107) when the constant JSON pointer `SCRATCH_PATH` ("/scratch") fails to convert into a json_patch `PatchOperation` path type. It means the hard-coded RFC-6901 JSON pointer string could not be parsed/validated by the json-patch crate. Because the value is a compile-time constant, in practice this only fires if the json-patch crate version changes its path parsing/validation so that "/scratch" is rejected. It is a programming/dependency invariant failure, not a data-driven error.

Source

Thrown at crates/services/src/services/events/patches.rs:107

                .try_into()
                .expect("Workspace path should be valid"),
        })])
    }
}

/// Helper functions for creating scratch-specific patches.
/// All patches use path "/scratch" - filtering is done by matching id and payload type in the value.
pub mod scratch_patch {
    use super::*;

    const SCRATCH_PATH: &str = "/scratch";

    /// Create patch for adding a new scratch
    pub fn add(scratch: &Scratch) -> Patch {
        Patch(vec![PatchOperation::Add(AddOperation {
            path: SCRATCH_PATH
                .try_into()
                .expect("Scratch path should be valid"),
            value: serde_json::to_value(scratch).expect("Scratch serialization should not fail"),
        })])
    }

    /// Create patch for updating an existing scratch
    pub fn replace(scratch: &Scratch) -> Patch {
        Patch(vec![PatchOperation::Replace(ReplaceOperation {
            path: SCRATCH_PATH
                .try_into()
                .expect("Scratch path should be valid"),
            value: serde_json::to_value(scratch).expect("Scratch serialization should not fail"),
        })])
    }

    /// Create patch for removing a scratch.
    /// Uses Replace with deleted marker so clients can filter by id and payload type.
    pub fn remove(scratch_id: Uuid, scratch_type_str: &str) -> Patch {
        Patch(vec![PatchOperation::Replace(ReplaceOperation {

View on GitHub (pinned to 4deb7eca8f)

Solutions

  1. Check the json_patch/jsonp dependency version in Cargo.toml/Cargo.lock; pin to a version whose `Pointer: TryFrom<&str>` accepts "/scratch" or run `cargo update -p json-patch` to a compatible version.
  2. Verify SCRATCH_PATH is a valid RFC-6901 pointer (non-empty, starts with '/'); if you changed it, restore `const SCRATCH_PATH: &str = "/scratch";`.
  3. If the new library requires a different path construction, build the Pointer via its API (e.g. `Pointer::parse("/scratch")` or builder methods) instead of `try_into()` and handle the Result explicitly.
  4. As a last resort, replace `.expect()` with a lazy static/OnceCell that parses once at startup and surfaces the error loudly there.

Example fix

// before
path: SCRATCH_PATH.try_into().expect("Scratch path should be valid"),
// after
static SCRATCH_POINTER: Lazy<Pointer> =
    Lazy::new(|| Pointer::parse(SCRATCH_PATH).expect("SCRATCH_PATH must be a valid JSON pointer"));
...
path: SCRATCH_POINTER.clone(),
Defensive patterns

Strategy: validation

Validate before calling

// Before constructing add-patches, assert the constant parses on this json_patch version:
fn assert_scratch_path_valid() {
    let p: Result<json_patch::Pointer, _> = "/scratch".try_into();
    assert!(p.is_ok(), "SCRATCH_PATH incompatible with json_patch version");
}
// In tests: #[test] fn scratch_path_is_valid_pointer() { assert_scratch_path_valid(); }

Type guard

fn is_valid_pointer(s: &str) -> bool {
    <json_patch::Pointer as TryFrom<&str>>::try_from(s).is_ok()
}

Try / catch

// expect() panics cannot be caught; fail fast in CI instead:
let ptr = Pointer::parse(SCRATCH_PATH)
    .unwrap_or_else(|e| panic!("invalid SCRATCH_PATH {SCRATCH_PATH}: {e}"));

Prevention

When it happens

Trigger: Calling `Patch::add(&scratch)` when `SCRATCH_PATH.try_into()` fails — practically only after upgrading/switching the json_patch dependency so that "/scratch" is no longer a valid `jsonp::Pointer` (e.g. stricter RFC-6901 validation or changed `TryFrom<&str>` impl).

Common situations: Version changes of `json-patch`/`jsonp` in Cargo.lock or Cargo.toml after `cargo update`; swapping the patch library for one with a stricter path type; refactoring SCRATCH_PATH into a value that is an invalid JSON pointer (must start with '/').

Related errors


AI-assisted analysis of BloopAI/vibe-kanban@4deb7eca8f (2026-08-29). Data as JSON: /api/errors/f32dcd6c903318d2. Report an issue: GitHub.