Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Expose checked-AST output type from cel.Engine/CompiledExpression

Aperta
  • Qualcosa non va?
#239 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go
Ambito
backend-api-design

Direzione di ricerca

Inizia da cel.Engine.Compile e dal CompiledExpression opaco, quindi confronta le informazioni disponibili di cel.Ast.OutputType(). Esamina la documentazione di compileActorMatcher e l’API proposta OutputType o CompileBool. Il lavoro è completo quando i chiamanti possono rifiutare le espressioni non booleane durante la compilazione invece che a ogni valutazione in fase di esecuzione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

needs-triage

cel.Engine.Compile type-checks an expression against the declared variables but only returns an opaque *CompiledExpression — there's no way for a caller to ask "does this expression statically return bool?"

This matters for callers who want config validated at admission/reconcile time rather than discovering a wrong-type expression on the first live evaluation. Concretely: ToolHive's operator lets admins author a CEL expression (actorMatcher) that must evaluate to bool. Something like "engineering" or 1 type-checks fine (any expression over the declared variables compiles), so it passes config validation, gets reported as valid, and then fails on every runtime evaluation via EvaluateBool's runtime type assertion — a config mistake that could have been caught once at reconcile time instead surfaces as an operational failure repeatedly.

cel-go's own cel.Ast.OutputType() already exposes this from the checked AST — cel.Engine.Compile just doesn't surface it. Proposed API, e.g.:

func (ce *CompiledExpression) OutputType() *cel.Type

or a narrower Engine.CompileBool(expr string) (*CompiledExpression, error) that rejects non-bool statically in one call.

Reference: stacklok/toolhive#6364 (review comment) — code currently documents this gap in compileActorMatcher's doc comment rather than working around it.

Lingua principale
Go
Stelle
2
Fork
5
Merge medio
1g 16h
PR unite (30g)
84

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stacklok/toolhive-core

Tutte le issue di stacklok/toolhive-core

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.