Repository navigation
Windows: source-scoped research paths exceed native file and process directory limits #7363
Description
Problem
On native Windows with the existing OS long-path policy unchanged, source-scoped research storage adds goal-sources/<namespace SHA-256>/benchmark/trajectory-assessments/<owner SHA-256>/packs/<pack SHA-256>.tmp. Even a short disposable root can exceed ordinary Win32 path limits before a provider starts.
The real RuntimeWorkspaceServer + register_pack path fails at trajectory_assessment._write with FileNotFoundError when creating the pack manifest. Separately, using the extended path namespace fixes Python file IO but a provider working directory beyond the supported CreateProcess length fails with WinError267. Increasing a request timeout or changing the model cannot repair this storage/process boundary.
Evidence and scope
- Source baseline: main e905d34; native Windows / CPython3.12.10.
- Observed through the existing
test_source_goal_analysis_reads_cancel_retry_and_reuse_do_not_mutate_sourceHTTP/store fixture after replacing POSIX-only source placeholders with native absolute synthetic paths. - Default pytest roots fail even earlier in the local-only fixture. A bounded temporary root permits the complete local HTTP journey, but source namespacing introduces the additional depth above.
- The source-scoped failure occurs before provider dispatch. Only synthetic executables were used; no live Goal, account, solver, model or benchmark job was involved.
- This does not establish UNC, network-volume or all Windows-version behavior. No storage hash, namespace isolation, receipt identity, assertion or authority check was shortened or bypassed.
Owning boundary / expected result
Existing source-scoped research storage and native process/file adapter, under the research journey tracked in #5205. Native source analysis should create/read its namespaced manifest and complete an authorized synthetic process journey without a machine-wide policy change or namespace collisions. Preserve source pinning, owner isolation, cancellation/retry and source-byte integrity. The eventual fix needs real file + native process evidence and a discriminating negative control; local-only fixture qualification cannot close this issue.
Activity
BigDataDZ commentedon Oct 26, 2026
The fixture repair in #7364 qualifies the 12 local HTTP cases using native synthetic executables and owned cleanup. It does not claim to fix this namespaced source-storage/process boundary; those source cases remain unqualified and explicitly excluded from the new local Windows CI step. The confirmed native source-scoped failure occurs before provider dispatch, and its fixture directory now cleans up without a secondary teardown error.
Dante-dan commentedon Oct 26, 2026
I am investigating the two native boundaries separately. In current
main,trajectory_assessment_store._ownerpasses the full namespaced path to ordinary file operations, whiletrajectory_assessment.executealso uses the durablejobs/<analysis_key>directory as the provider working directory. Addressing file IO alone therefore cannot address the process failure you observed.I will try reusing the existing Windows extended-path adapter for the durable store, and using an owned, short temporary working directory only when a Windows provider cannot use the durable path as its cwd. The full source namespace, owner and analysis hashes, durable lock/receipt location, and source verification will stay intact. The provider already receives absolute schema/output paths and has tools disabled; this should avoid a storage-layout migration or system policy change.
The decisive check will be a native file-and-process regression with a negative control, alongside cancellation/retry and unchanged source bytes. I will keep the Windows qualification gap explicit until that runs; the fixture-only work in #7364 remains separate.