Modal worker canonical Volume paths are rejected by lexical result validation

Summary

On release/v0.1.0, a Modal worker can safely publish a completed result through the canonical physical namespace of the Volume mounted at /data, but the controller rejects that result because it accepts only lexical /data/... path strings. This occurs after the worker has written a completed durable checkpoint and artifact archive.

Minimal reproduction

Use the existing Modal provider result fixture with a generic external Solidity target:

1. Let the controller derive an attempt root under /data/ultrafuzz-nodes/....
2. Return a readable result envelope whose artifact archive, completed checkpoint, and checkpoint index use the exact corresponding /__modal/volumes/vo-example/ultrafuzz-nodes/... paths.
3. Make the mocked Modal filesystem resolve both namespaces to the same files.
4. Keep the storage lineage, logical dispatch fingerprint, execution generation, archive digest, checkpoint stage, and every attempt-relative suffix unchanged.
5. Run the provider against the already-published result.

Observed:

Modal node execution failed: cloud node result is invalid

The initial rejection is the exact lexical comparison in readModalNodeResult(). If only the result-envelope references are made lexical, validateDurableCheckpoint() then rejects the worker-persisted canonical workspace_path, handoff_archive, and checkpoint-index manifest references.

Expected behavior

The provider should accept either its lexical attempt root or exactly one consistent canonical Modal Volume prefix when the exact expected attempt-relative suffix is preserved. The following bindings must remain strict:

• storage lineage and execution generation;
• logical dispatch fingerprint;
• run and execution-snapshot roots;
• completed checkpoint stage;
• archive digest;
• exact artifact, workspace, handoff, checkpoint, and index suffixes;
• one consistent canonical prefix across checkpoint and index metadata.

Mixed canonical prefixes, unrelated Volume-relative suffixes, traversal, wrong checkpoint manifests, and changed dispatch fingerprints should remain rejected.

Impact

The inner node can complete and persist recoverable artifacts, yet the outer workflow records a failure solely because worker and controller name the same Modal Volume through different namespaces. Subsequent retries cannot adopt the completed publication.

Duplicate search

Searched open and closed issues for canonical Modal Volume result paths, the reported error, and durable-checkpoint /data namespace mismatches. No matching concrete report was found.

Start with readModalNodeResult() and the Modal provider result fixture, then trace validateDurableCheckpoint() for the workspace, handoff, and checkpoint-index references. Reproduce the generic external Solidity target case with lexical and canonical Volume paths. Done means one consistent canonical prefix is accepted with exact suffixes and metadata, while mixed prefixes, traversal, incorrect manifests, and changed fingerprints remain rejected.