Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Geschlossen
  • Stimmt etwas nicht?
#3,876 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Ein zugehöriger Pull Request wurde bereits gemerged.

  • #3879 von @thymikee — gemerged

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
node.js, typescript
Bereich
backend, devtools

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
5.1k
Forks
339
Ø Merge
12 Std. 22 Min.
Gemergte PRs (30 T.)
701

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus callstack/agent-device

Alle Issues in callstack/agent-device

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.