Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#3,876 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@thymikee y travaille déjà.

Depuis le 21/10/2026.

  • #3879 par @thymikee — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Refactorisation
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
node.js, typescript
Domaine
backend, devtools

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
5.1k
Forks
339
Merge moyen
11 h 59 min
PR mergées (30 j)
736

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de callstack/agent-device

Toutes les issues de callstack/agent-device

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.