Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#3,049 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
30/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
api, backend-api-design, developer-experience

Piste de recherche

Commencez par le UpdateConfigRequest actuel dans proto/openshell.proto, puis utilisez l’audit du code source lié et examinez l’issue #1988 pour les contraintes de politique prises en charge par le fournisseur. Cartographiez la CLI, la TUI, le SDK, le protobuf binding, le handler, la documentation et les migration consumers avant de choisir entre des RPCs séparés et un mutation oneof. Le travail est terminé lorsque les contrats typés, le comportement d’autorisation et de concurrence, les tests et les intégrations listées sont mis à jour de manière cohérente.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Rust
Étoiles
15.4k
Forks
1.7k
Merge moyen
1 j 21 h
PR mergées (30 j)
358

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de NVIDIA/OpenShell

Toutes les issues de NVIDIA/OpenShell

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.