Proxy lease refuses every iOS install/open: connection platform 'ios' compared with internal 'apple'
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 78/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- cli, mobile-dev
调研方向
从 src/cli/commands/connection-runtime.ts 中的 applyResolvedDeviceSelector（大约第 888-898 行）和 assertRequestedConnectionScope（大约第 955-961 行）开始。跟踪 publicPlatformString 和 buildProxyDeviceKey，然后使解析后的平台与连接的公共平台保持一致。使用 iOS 代理租约进行复现并安装或打开，然后确认 Android 的行为保持不变。
由索引模型根据 Issue 内容生成。
描述
Summary
With a proxy lease, every iOS install and open on a remote connection is refused with:
Error (INVALID_ARGS): Active remote connection is already bound to a different platform. Re-run connect --force to replace it.
even though the connection was opened for iOS and the request targets that same iOS device. Android is unaffected.
Cause
When the lease state resolves a device, applyResolvedDeviceSelector copies the device's internal platform into the request flags:
For an iOS-family device that value is the internal apple, not the public ios. assertRequestedConnectionScope then compares it with the connection's stored public platform:
so ios !== apple and the request is refused. Android passes because its internal and public names are both android.
Repro
agent-device 0.21.12 (same code on main at 76dbee0): open a remote connection with platform: ios and a proxy lease, then run install <app> (or open) against the leased device. It fails right after the device lookup, before a lease is taken.
Possible fix
Store the public name in the flags, e.g. flags.platform = publicPlatformString(device) (already used by buildProxyDeviceKey in the same file), or normalize both sides before the comparison.
Context
Found through Stim (appandflow/stim#1096). Stim works around it by keeping iOS on the default 60 s lease (appandflow/stim#1127), which means large iOS apps can still hit #2946 (lease not renewed during upload); fixing this would let iOS use the longer proxy lease.
- 主要语言
- TypeScript
- 星标
- 4.7k
- 派生
- 304
- 平均合并
- 11 小时 19 分钟
- 30 天内合并 PR
- 539
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
callstack/agent-device 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
callstack/agent-device#1869 ·
维护者通常 1 天内回复
-
needs-triage refactor
难度 5/5 一周以上 新手友好度 28/100
callstack/agent-device#2976 ·
维护者通常 1 天内回复
-
ready-for-agent refactor
难度 4/5 3-5 天 新手友好度 48/100
callstack/agent-device#2974 ·
维护者通常 1 天内回复
-
needs-triage refactor
难度 4/5 3-5 天 新手友好度 35/100
callstack/agent-device#2973 ·
维护者通常 1 天内回复
-
ready-for-agent refactor
难度 4/5 3-5 天 新手友好度 42/100
callstack/agent-device#2972 ·
维护者通常 1 天内回复
查看 callstack/agent-device 的全部 Issue
相似的 Issue
-
module-request
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 90/100
appandflow/stim#1604 · 1 条评论 ·
维护者通常 1 天内回复
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
难度 1/5 1 小时以内 新手友好度 92/100
lingdojo/kana-dojo#31060 · 1 条评论 · 5 个 reaction ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 90/100
paperclipai/paperclip#14173 ·
维护者通常 1 天内回复
-
needs-triage
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复