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

Track held execution locks in keyed-lock instead of a request-level registry

Chiusa
  • Qualcosa non va?
#3,876 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #3879 di @thymikee — integrata

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
node.js, typescript
Ambito
backend, devtools

Direzione di ricerca

Read packages/kernel/src/keyed-lock.ts and packages/daemon/src/server/request-execution-locks.ts first, then inspect their existing tests and the crossed-replay and nested-batch cases. The linked pull request indicates work is already underway. Done when the keyed lock tracks retained frames across sibling scopes, request execution locks has no separate registry, the specified cancellation and same-host behaviors pass, and the close-refusal test uses the production platform refusal.

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

Descrizione

needs-triage

Purpose

#3323 makes each native macOS app its own device. It adds a rule: a request that already holds an execution lock on a Mac, or on one of its app devices, does not wait for a second lock on that same Mac. Instead it takes the lock only if it is free, and otherwise it is refused with DEVICE_IN_USE (DEVICE_EXECUTION_LOCK_BUSY).

To answer "which locks does this request hold, including those of the requests it is nested in", packages/daemon/src/server/request-execution-locks.ts keeps a second registry next to the kernel keyed lock:

  • an enclosingRequestLocks AsyncLocalStorage;
  • a per-request heldLocks set;
  • a beforeAcquire hook on withRequestExecutionLockKeys;
  • two re-entry special cases.

The kernel keyed lock (packages/kernel/src/keyed-lock.ts) already tracks the locks held by the current async context, except for retained ones. Reviewer suggestion: https://github.com/callstack/agent-device/pull/3323#issuecomment-6322558994.

Required behavior

  • packages/kernel/src/keyed-lock.ts owns the answer to "which keys of this lock map does the current async context hold". The answer includes locks retained mid-request (what retainDevice takes).
    • Sketch: a holdKeyedLock(locks, key, signal) that acquires the key and registers its frame in the caller's context, plus a heldKeyedLockKeys(locks) query.
  • request-execution-locks.ts applies the same-host rule as one check against that query. The enclosingRequestLocks store, the heldLocks set and the two re-entry special cases are deleted.
  • Behavior stays as in #3323:
    • A top-level request still waits for its own initial keys in sorted order (host before app).
    • A nested request (batch step) and a mid-request retain take a lock on a Mac already held in the context only if it is free; otherwise they are refused with DEVICE_EXECUTION_LOCK_BUSY.
    • A key that the context already holds is re-entered.
    • Locks on other devices are still waited for.
    • The #3858 cancellation signal still ends a queued lock.

Pitfalls to handle

  • withKeyedLock gives each nested scope a copy of the frame list. A frame registered by a retain inside a nested scope must stay visible to later sibling scopes of the same request, and must be released when the request ends. Example: a replay action retains through its parent's scope.
  • The same-host rule has to tell the request's own earlier initial keys apart from keys held by enclosing requests. Otherwise a top-level open (host, then app) would stop waiting for its own app lock.

Also in scope

  • The close-refusal test in packages/daemon/src/sessions/handlers/__tests__/session-device-claims.test.ts currently hand-writes the platform error. Build it from the production platform refusal instead: resolveMacOsAppDeviceOpenTarget with a stub host, where the test layering allows it.

Completion conditions

  • The current tests pass unchanged or stronger. In particular:
    • request-execution-locks.test.ts, including the crossed-replay and nested-batch cases;
    • request-router-app-device-batches.test.ts;
    • the #3858 cancellation tests.
  • A kernel test covers a retained frame that is visible to later sibling scopes and is released at the end of the request.
  • request-execution-locks.ts keeps no lock registry of its own.

Dependencies

Blocked by: #3323. It must merge first, because this issue refactors the code that #3323 adds.

Lingua principale
TypeScript
Stelle
5.1k
Fork
339
Merge medio
12h 22m
PR unite (30g)
701

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 callstack/agent-device

Tutte le issue di callstack/agent-device

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.