Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
  • 哪里不对？
#3,876 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

已经有一个关联 PR 被合并了。

  • #3879 来自 @thymikee —— 已合并

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
重构
描述清晰度
描述清楚
活跃度
停滞
技术栈
node.js, typescript
领域
backend, devtools

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
TypeScript
星标
5.1k
派生
339
平均合并
12 小时 50 分钟
30 天内合并 PR
632

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

callstack/agent-device 的其他 Issue

查看 callstack/agent-device 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。