Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

feat(api)!: split UpdateConfig into typed policy and settings mutations

Offen
  • Stimmt etwas nicht?
#3,049 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
30/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
api, backend-api-design, developer-experience

Rechercherichtung

Beginne mit dem aktuellen UpdateConfigRequest in proto/openshell.proto, verwende anschließend das verknüpfte Source Audit und untersuche Issue #1988 auf provider-gestützte Richtlinienbeschränkungen. Erfasse CLI, TUI, SDK, protobuf binding, handler, documentation und migration consumers, bevor du dich zwischen separaten RPCs und einem mutation oneof entscheidest. Abgeschlossen bedeutet, dass die typisierten Verträge, das Autorisierungs- und Nebenläufigkeitsverhalten, die Tests und die aufgeführten Integrationen konsistent aktualisiert sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

help wanted

User Story

As an API client and operator, I want policy changes and setting changes represented as distinct typed operations, so that each request has unambiguous validation, authorization, and concurrency semantics.

Problem Statement

UpdateConfigRequest combines full policy replacement, incremental policy merge operations, setting upsert, setting deletion, sandbox/global scope, annotations, and optimistic-concurrency fields. Optional fields and action booleans encode mutually exclusive operations only through prose and handler validation. The field named global is also awkward or invalid for normal attribute access in some generated languages.

Impact / Why This Matters

Callers can construct contradictory requests, SDK wrappers must invent their own validation, and the most privileged configuration mutation surface is also the least type-constrained. Policy and settings have different authorization, deletion, versioning, and lifecycle behavior, making one generic response difficult to evolve safely.

Proposed Design

Expose distinct typed operations for policy and setting mutations, with request and response types that carry only fields meaningful to that operation. At minimum, the public contract must separately express:

  • sandbox policy replacement or merge;
  • global policy mutation, if retained;
  • setting upsert; and
  • setting deletion.

Use typed scope selectors rather than global and action booleans. Define optimistic concurrency, annotations, authorization, and returned state for each operation. Internal handlers may share implementation.

Acceptance Criteria

  • No public mutation request relies on unrelated optional fields or action booleans to select the operation.
  • Policy replacement/merge and setting upsert/delete have typed request and response contracts.
  • Sandbox and global scopes are explicit and cannot be combined incorrectly.
  • Authorization requirements are documented and enforced per operation.
  • Optimistic-concurrency behavior and ABORTED responses are consistent and tested.
  • Policy is no longer represented as a magic entry in the settings map.
  • CLI, TUI, all SDKs, protobuf bindings, docs, and migration notes are updated.
  • Old fields and RPCs are removed or deprecated with reserved names/tags as appropriate.

Alternatives Considered

Keep one RPC but replace its fields with a mutation oneof. This would make invalid combinations unrepresentable and may be acceptable if common authorization and response semantics are retained. Separate RPCs are preferred when operations have materially different permissions, concurrency, or results.

Agent Investigation

The current request in proto/openshell.proto contains policy, setting, delete, global-scope, merge-operation, concurrency, annotation, and workspace fields. Provider-backed policy composition in #1988 must remain coherent with the new boundary.

Related: #2565, #1988. Source audit: https://gist.github.com/mrunalp/e80942c1544a0225ee588796a41ab30b.

Vorherrschende Sprache
Rust
Sterne
15.4k
Forks
1.7k
Ø Merge
1 T. 21 Std.
Gemergte PRs (30 T.)
358

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus NVIDIA/OpenShell

Alle Issues in NVIDIA/OpenShell

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.