Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Fechada
  • Algo errado?
#3,876 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Um pull request relacionado já foi integrado.

  • #3879 de @thymikee — integrado

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Refatoração
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
node.js, typescript
Domínio
backend, devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
5.1k
Forks
339
Merge médio
12h 22min
PRs com merge (30d)
701

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de callstack/agent-device

Todas as issues de callstack/agent-device

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.