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

deploy: atomically claim and own pending Agent Runtime operations

Aperta
  • Qualcosa non va?
#76 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

@asrujana-44 ci sta già lavorando.

Dal 17/9/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
cli, cloud

Direzione di ricerca

Partite dal percorso di deployment di Agent Runtime nel baseline e confrontatelo con il branch Batch 4 del fork collegato, concentrandovi sulle transizioni read/modify/write di deployment_metadata.json. Eseguite le regressioni di race e failure di thread/subprocess menzionate, quindi verificate esattamente un owner e una mutation, un ripristino byte-identical per i failure pre-submit, uno stato iniziale fail-closed per gli esiti incerti e un completamento e cleanup owner-safe.

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

Descrizione

Summary

Agent Runtime deployment operation state in v1.3.1 is a non-atomic read/modify/write record without an owner token. Two CLI processes can both pass the pending-operation check, start remote mutations, and overwrite or clear each other's deployment_metadata.json state.

Baseline: 5a306f8956cb1eeae69f9709de0e4d61b44e11e7 (v1.3.1).

Reproduction

  1. In one agent project, start two agents-cli deploy --no-wait processes at the same time.
  2. Both read the metadata before either writes its pending operation.
  3. Observe that both may submit a remote create/update, while the last metadata write wins.
  4. Also simulate:
    • local SDK request-config construction failing before remote submission;
    • remote create/update submission raising with an unknown outcome;
    • a delayed status/cleanup process running after a newer operation replaced the record.

Actual behavior

  • More than one remote mutation can start.
  • One process can overwrite or clear another process's pending operation.
  • A crash between remote submission and operation-name persistence is not represented safely.
  • Failure cleanup cannot distinguish known pre-mutation failure from outcome-uncertain remote submission.

Expected behavior

  • Exactly one process owns the right to start a mutation.
  • Ownership spans target revalidation, remote submission, status recording, completion, and cleanup.
  • Local preparation failure restores prior metadata byte-for-byte.
  • Once remote submission or identity creation may have happened, retain a fail-closed starting claim for manual reconciliation.
  • A stale owner must never clear a replacement owner's record.
  • Successful completion should merge current sibling metadata and remove the owned claim in one atomic transition.

Minimal fix

Use a cross-process lock around metadata read/modify/write, add a random claim ID, claim before remote mutation, revalidate the selected Runtime while holding ownership, and make clear/finish operations owner-aware. Split local request preparation from remote submission so only errors proven to precede mutation restore the previous bytes.

Reference implementation and regressions: fork Batch 4 branch.

Verification evidence

  • Thread and subprocess races each produced exactly one owner and exactly one mutation.
  • Replacement-owner, legacy-operation, atomic-finish, and sibling-metadata regressions passed.
  • Local request-config failure: zero mutation, byte-identical restoration, retry claim succeeds.
  • Remote submit and identity-create outcome-uncertain failures retain state=starting.
  • Fresh targeted review: 35 tests passed; full local suite: 92 passed.
  • ruff check src tests, ty check src, build, and Python 3.11/3.13 installed-wheel smoke tests passed.
Lingua principale
Python
Stelle
6k
Fork
670
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

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 google/agents-cli

Tutte le issue di google/agents-cli

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.