Project administration: revision-guarded single-field update instead of config overwrite

Summary

On WebCodex v0.4.6 (Server/Runner aligned; Windows x64), the caller-visible project administration surface exposes list_projects and register_project(overwrite=true), but no documented revision-guarded single-field update for an existing Project. For an administrator who needs to change only allow_patch, register_project(overwrite=true) documents full configuration replacement and its input contract does not include expected_revision.

This is an administrative usability and concurrency-safety feature request, not a request to weaken any authorization or platform policies.

Evidence and scope

Observed directly through the WebCodex model-visible tool manifest for a v0.4.6 deployment: register_project accepts allow_patch and overwrite, but not expected_revision.
list_projects returns a Project revision value.
unregister_project supports revision guarding for deletion but is not a configuration edit operation.
Not verified: whether there is already a trusted private administration implementation that handles this safely, or whether current upstream main has an equivalent interface.
No overwrite or change was attempted, and no project or running Job was modified.

Requested behavior

First identify and document any already-supported trusted administrator path for updating a specific existing Project field. If none exists, consider a narrowly authorized update_project_settings/equivalent operation with:

Exact Project identity and mandatory expected_revision.
An allowlisted set of editable fields (initial use case: allow_patch), with the ordinary authorization and policy checks intact.
Atomic compare-and-update; concurrent/stale revisions must reject without mutation.
Preservation of every non-target field, registered identity, Runner binding, and unrelated Project.
Crash-safe persistence and an auditable redacted before/after revision and changed-field receipt.
No side effect on already running Jobs and no override of other independent platform approvals.

Acceptance tests

Matching revision + authorized administrator changes exactly the designated field.
Stale revision, wrong Project, unauthorized principal, unknown field and overlapping update fail without changes.
Simulated interrupted persistence yields a valid complete old or new config, never a partial file.
Unrelated Project settings, worktrees and active Jobs stay unchanged.
Document the approved administrator-facing contract, return evidence and rollback.

A maintainer response identifying an existing equivalent workflow is equally useful. Please clarify whether the current upstream main already addresses this.

Privacy: This public issue deliberately excludes local machine identities, private repository names, credentials, configuration contents, service endpoints, and internal security review details.

No release or deployment is requested; this is a feature/maintenance triage request only.

Thanks for the detailed report and for spelling out the concurrency and safety requirements so clearly. We appreciate you continuing to use WebCodex and sharing this feedback.

We've checked this against v0.5.0 and current main, and you're right: there isn't yet a supported, revision-guarded way to update just one existing Project setting such as allow_patch.

This is a reasonable improvement to the administration workflow. We'll keep the issue open and include it in our future planning. We'd like any eventual implementation to reuse the existing Project revision and authorization safeguards, preserve unrelated settings, and reject stale updates rather than rely on full-config overwrites. We don't have a target release to announce yet.

In the meantime, since you're running v0.4.6, we'd recommend upgrading both Server and Runner to v0.5.0 when convenient, following the upgrade guidance. Just to be clear, v0.5.0 does not add the requested single-field update operation yet.

Thanks again for the thoughtful suggestion!

Thank you for the update. We inspected the v0.4.6 source at 5072608fe74b2bfa6e8f208515c04242f475582f: the admin Projects UI and routes appear to expose registration, creation, and lifecycle operations, while expected_revision is used for lifecycle actions rather than a single-field update to an existing project's allow_patch setting. We have not verified the live admin console in this check and have not overwritten or re-registered the project.

Is there an officially supported administrative procedure in v0.4.6 that changes only allow_patch, preserves all other settings, and rejects stale revisions or concurrent updates? If not, please confirm whether this requires the planned feature, and whether any supported migration path exists that preserves the existing project and running jobs.

We would like to contribute a focused fix for this issue. Would maintainers accept an implementation proposal or a draft PR for an admin-authorized, revision-guarded update of only allow_patch on an existing project? The intended behavior would preserve all other settings and reject stale or concurrent updates, with targeted authorization, preservation, and concurrency tests.

The contribution guide describes the standard branch and PR workflow. If there is a preferred design, API shape, or other contribution procedure for this change, please let us know before implementation. No patch or PR is being claimed in this request.

Thanks for offering to contribute — we'd be happy to review a focused implementation or draft PR!

Please target the current main branch rather than v0.4.6; we're not planning to add new features to the 0.4.6 series.

For this change, we'd prefer to keep the initial scope narrow: an admin-authorized, revision-guarded update of allow_patch on an existing Project. Please reuse the existing Runner-side Project lifecycle/registry mechanisms where practical, preserve all unrelated settings and Project identity, and include focused tests for authorization, stale/concurrent revisions, and persistence safety. A short design outline in the draft PR is perfectly fine if you'd like early feedback before completing the implementation.

To answer your earlier question explicitly, we haven't identified a supported v0.4.6 administrative API that provides all of those guarantees for a single-field update. We wouldn't recommend register_project(overwrite=true) as a substitute.

Thanks again for taking the initiative!

Thank you for accepting the focused fix. I confirmed that PR #1393 was merged on 2026-11-08 (merge commit a22299e973fbe6c411982b819dc70d3b4888fd9d) and that the new admin API requires the separately negotiated project_settings_update Runner capability.

We're still running v0.4.6 Server/Runner with existing active Jobs, and the latest official release I can verify is v0.5.0 (published before that merge). We will not deploy an unreleased build or use register_project(overwrite=true) to change the existing Project.

Could the maintainers please clarify, when known:

Which first official Server + Runner release/tag will include feat(projects): revision-guarded admin allow_patch update #1393, so we can verify the exact provenance rather than infer support from main?
Whether the published upgrade procedure supports preserving existing Project identity/configuration and ongoing detached Jobs from a v0.4.6 installation, or whether those Jobs must first finish and be independently verified?
Whether any Windows-native testing of the admin endpoint + matching Runner capability is planned before such a release?

No urgent rollout request or unsupported v0.4.6 backport is intended. We will wait for a supported release and perform isolated validation before any production change. Thank you.

Thanks for following up and for the careful verification of #1393!

The change is now merged into main, and we're tentatively targeting v0.5.1 for release this week or next week, subject to testing and release readiness. This is not a firm release date yet.

You're also very welcome to build the current main branch from source and try it ahead of the release. Please build/update both Server and Runner, since the new admin operation requires the independently negotiated project_settings_update Runner capability. Feedback—especially from Windows—would be very helpful.

For your existing v0.4.6 deployment, we can't yet guarantee continuity of in-flight detached Jobs across a Server/Runner restart. We recommend testing an early build in an isolated environment rather than upgrading a production instance while those Jobs are active. We'll aim to clarify upgrade guidance and Windows validation as part of release preparation.

Thanks again for your continued interest and contributions!

Follow-up with new native Windows Server+Runner E2E evidence for the merged #1393 admin API (all in an isolated local test instance, not HOME/Production):

On a pinned detached checkout of merge commit a22299e973fbe6c411982b819dc70d3b4888fd9d, we built matching webcodex-server.exe + webcodex-runner.exe under Windows 11/MSVC, ran 44/44 focused Rust tests (pass), and completed a real loopback Server/Runner admin lifecycle test.
New disposable Project registered with allow_patch=false (HTTP 200). Stale Revision rejected 409; extra JSON field rejected 400; update false→true 200 with a new Revision; rollback true→false 200. A fresh Server+Runner restart recovered the exact original Project identity, Revision and allow_patch=false. Concurrent same-revision HTTP updates returned exactly one 200 and one 409; foreign Origin rejected 403. Registry TOML was byte-identical after rollback, original Project sentinel preserved, test processes and temporary credentials removed.
Separate Windows path compatibility observation worth a small follow-up: src/admin_project_lifecycle.rs::validate_common currently requires path.starts_with('/'). Passing the ordinary existing Windows absolute path D:\AUTO_GO_STAGING\...\preserve-project to POST /api/admin/projects/register returned 400 invalid_request. Passing the same canonical existing D: directory as a Windows verbatim path with forward separators //?/D:/AUTO_GO_STAGING/.../preserve-project passed this validator and registered successfully (200). It would be helpful to clarify/document the supported Windows native path format or adjust input validation without relaxing the Runner's canonical root/allowed-roots safeguards. This concerns new admin Project registration, not the already-registered Project's update_allow_patch behavior.
Our actual test Project had active_jobs=0. We are not claiming that v0.4.6 HOME detached running Jobs can safely survive a live upgrade; no official post-merge release exists yet.

Thank you for merging the fix. This is a test report / compatibility note rather than a request to backport or deploy an unsigned binary.

Thank you for the detailed native Windows 11 Server+Runner E2E report for #1393. The revision checks, concurrent-update result, restart persistence, and cleanup evidence are especially useful.

We also checked the separate Windows project-registration path observation. You were right: the admin adapter was using a POSIX-only path.starts_with('/') preflight check. We've opened PR #1413 to reuse the existing cross-platform Project path validator for the admin register and create routes. This accepts ordinary Windows absolute path shapes (for example D:\projects\demo) without requiring the //?/D:/... workaround; the Runner still independently enforces canonicalization, native path validity, authorization, and allowed_roots. Existing update_allow_patch behavior from #1393 is unchanged.

The PR has now been reviewed on macOS/mini with no blocking findings: the two new HTTP path tests passed, all 47 admin-focused tests passed, and the shared path-validator test plus formatting/docs checks passed. Cross-platform CI is still in progress, and we have not yet repeated a live native-Windows registration E2E for #1413. We'll wait for the required CI checks before merging and would welcome additional native Windows feedback afterward.

As before, no v0.4.6 backport or official release is being announced by this comment. The prospective v0.5.1 timing remains tentative, and continuity of in-flight detached Jobs across a Server/Runner restart is not guaranteed; please keep active production Jobs out of upgrade acceptance tests.

Thanks again for reporting the precise path discrepancy and for keeping the verification isolated from your production installation.

Navigation Menu

Repository navigation

Project administration: revision-guarded single-field update instead of config overwrite #1361

Summary

Evidence and scope

Requested behavior

Acceptance tests

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Project administration: revision-guarded single-field update instead of config overwrite #1361

Description

Summary

Evidence and scope

Requested behavior

Acceptance tests

Activity

swjnxyf commented on Nov 5, 2026

hanklee5677 commented on Nov 5, 2026

hanklee5677 commented on Nov 5, 2026

swjnxyf commented on Nov 5, 2026

hanklee5677 commented on Nov 9, 2026

swjnxyf commented on Nov 9, 2026

hanklee5677 commented on Nov 9, 2026

swjnxyf commented on Nov 9, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions