Clarify metadata propagation in OFREP provider guidelines
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Documentazione
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- documentation
Direzione di ricerca
Leggi guideline/dynamic-context-provider.md in Evaluation e guideline/static-context-provider.md in Initialization, Evaluation, Polling e Change context. Chiarisci la conservazione dei metadati per flag e il comportamento della cache del provider statico per le risposte 304 e 200, quindi determina se i metadati a livello di bulk rientrano in questo issue e come vengono esposti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Following the Slack discussion, I suggest explicitly defining how OFREP response metadata reaches OpenFeature flagMetadata. At Confidence, we want to carry an opaque resolve token through metadata so an after hook can report exposure when a cached flag is evaluated.
I suggest updating Evaluation in the dynamic provider guidelines, and Initialization, Evaluation, Polling, and Change context in the static provider guidelines, to specify:
- Preserve all valid per-flag metadata, including custom vendor keys, in resolution
flagMetadata. - Keep cached metadata associated with its value: retain it on
304, replace it on200, and clear old entries when omitted from the replacement.
Suggested wording for per-flag propagation to start a discussion:
Providers MUST preserve per-flag OFREP metadata in OpenFeature resolution flag metadata, retaining keys, values, and primitive types. Static providers MUST preserve this association when caching and updating evaluations.
I would also like to define how bulk-level metadata is exposed to applications and hooks, including whether it is merged into per-flag metadata and which keys take precedence. Not sure if we want to take that discussion in the same issue?
Are there existing implementations or cache semantics that would make these requirements problematic?
AI-assisted
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 57
- Fork
- 7
- Merge medio
- 23h 3m
- PR unite (30g)
- 1
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di open-feature/protocol
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
open-feature/protocol#83 · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
open-feature/protocol#73 · 2 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
open-feature/protocol#72 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
open-feature/protocol#71 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
open-feature/protocol#70 ·
Tutte le issue di open-feature/protocol
Issue simili
-
Check Trellix Links...Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
NetAppDocs/ontap#2151 ·
-
documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
nf-core/metaboigniter#132 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation hacktoberfest priority: low skill: good first issue status: ready for dev
Difficoltà 2/5 Mezza giornata Idoneità per principianti 85/100
hyperledger-labs/fabric-smart-client#2142 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
netbox status: needs owner type: documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
netbox-community/netbox#23412 · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno