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

Guest-execution slot counter has no near-threshold warning

Aperta
  • Qualcosa non va?
#1,912 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@SparshSunilNaik ci sta già lavorando.

Dal 30/8/2026.

  • #1923 di @SparshSunilNaik — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
78/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust, wasm
Ambito
backend, observability

Direzione di ricerca

Inizia in crates/v8-runtime/src/session.rs da SlotControl e SessionSlotPermit::try_acquire, poi leggi RuntimeMetrics::observe_executor in crates/runtime/src/metrics.rs e agentos_bridge::queue_tracker. Esegui i test dei permit esistenti e sollecita direttamente il contatore senza saturare gli isolate V8. Il lavoro è completato quando gli avvisi in prossimità della soglia e la visibilità della profondità della coda, dell’high-water mark e della capacità compaiono durante l’acquisizione e il rilascio al limite predefinito.

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

Descrizione

Problem

The process-wide guest-execution admission counter goes from silent to rejecting with nothing in between. Every other bounded limit in the repo warns first.

CLAUDE.md requires that every limit "be bounded by default, warn near threshold, and fail with a typed error that names the limit and how to raise it." This counter satisfies the first and third, not the second.

Where

SlotControl is a bare Arc<(Mutex<usize>, Condvar)> (crates/v8-runtime/src/session.rs:1047). Admission is fail-fast:

// crates/v8-runtime/src/session.rs — SessionSlotPermit::try_acquire
if *active >= maximum {
    return Err(format!("ERR_AGENTOS_GUEST_EXECUTION_LIMIT: ..."));
}
*active += 1;
metrics.observe_executor(ExecutorMetricClass::Vm, *active, 0);

RuntimeMetrics::observe_executor (crates/runtime/src/metrics.rs:477) only stores gauge values — it has no threshold evaluation and emits no warning:

pub fn observe_executor(&self, class: ExecutorMetricClass, active: usize, queued: usize) {
    executor.active.observe(active);
    executor.queued.observe(queued);
}

Meanwhile agentos_bridge::queue_tracker gives every registered limit edge-triggered warnings at WARN_FILL_PERCENT = 80 with hysteresis re-arm at REARM_FILL_PERCENT = 50. The slot counter is not registered with it.

Why it matters

This is the limit a parallel-agent fleet actually hits, and it's held for the whole lifetime of every guest process (JS, TS, Python, WASM command alike) — not just while it burns CPU. A host sitting at 63/64 looks identical in the logs to one sitting at 3/64, right up until an execution is rejected outright. There is no queue and no retry, so the first sign of trouble is a failed agent.

An 80% warning would have turned a run that dies at peak concurrency into a visible "you are near the ceiling, raise it" signal beforehand.

Suggested fix

Small, and the pieces already exist:

  • crates/v8-runtime already depends on agentos-bridge (crates/v8-runtime/Cargo.toml:13).
  • LimitCategory::Resource is documented as exactly this shape — "a saturating resource counter (fds, processes, sockets, bytes in use)".

Add a TrackedLimit::ActiveGuestExecutions variant, register it in SessionManager::new via register_limit(..., max_concurrency), and call QueueGauge::observe_depth(*active) from both SessionSlotPermit::try_acquire and its Drop. That yields the standard 80% warning, plus depth/high-water/capacity in queue_snapshot for free.

Worth confirming the warning is reachable at the default ceiling of 64 without a test that has to saturate real V8 isolates — the counter can be exercised directly, as the existing permit tests do.

Related

Adjacent to #1816, but not covered by it: that issue is scoped to VmLimits fields and per-VM observability, and its proposed audit ("the limits audit fails when a measurable limit lacks accounting") is keyed on VmLimits. This ceiling is process-scoped and deliberately not a VmLimits field, so it would fall through that net.

Context: found while making the ceiling operator-tunable on branch claude/maxactivevms-exposure-analysis-nd6qqa, which added AGENTOS_MAX_ACTIVE_GUEST_EXECUTIONS and a startup log of the effective value. The startup line tells you the ceiling; nothing tells you how close you are to it.

Lingua principale
Rust
Stelle
4.8k
Fork
272
Merge medio
13h 24m
PR unite (30g)
49

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 rivet-dev/agentos

Tutte le issue di rivet-dev/agentos

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.