Report the pending simulator command when platform initialization times out
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 52/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- ios, react-native, typescript
- 領域
- mobile-dev, testing
調査の方向性
Start from withPlatformReadyTimeout and PlatformReadyTimeoutError, then trace how runner initialization and finite simulator setup calls such as getAppInfo are invoked and whether they receive the session abort signal. Reproduce the pending app lookup with mocked subprocesses as described, since the timeout currently reports only the generic error. Done means the timeout includes the active operation, command, simulator identity and elapsed time, and finite simulator setup commands forward cancellation.
索引モデルが issue の本文から書いたものです。
説明
On Harness 1.5.0, an iOS Simulator command that stays pending during setup is reported only as:
The platform did not become ready within 420000ms. Increase "platformReadyTimeout" if your device, simulator, or emulator needs more time to start.
In this CI run, simctl bootstatus returned after about 4m 39s. Harness then started xcrun simctl appinfo <udid> com.margelo.nitro.example, with no further command completion before the seven-minute startup deadline. No tests ran:
https://github.com/margelo/nitro/actions/runs/40677820821/job/122787663933
The logs establish the pending startup operation, but do not establish why CoreSimulator stalled. This is separate from the missing-app exit-code handling in #223.
withPlatformReadyTimeout races the entire runner initialization against one generic timeout. It has no context about the current platform operation. Several finite simulator setup calls, including getAppInfo, also do not receive the session abort signal, so they can keep running after the setup deadline.
I reproduced the reporting behavior against the published packages with mocked subprocesses: non-zero boot/app lookup failures propagate their original errors, but a successful boot followed by a pending app lookup produces only PlatformReadyTimeoutError.
Could initialization report the active operation, command, simulator identity, and elapsed time on timeout, while forwarding cancellation through all finite simulator setup commands? That would distinguish a boot stall from an app lookup or installation stall without changing platformReadyTimeout.
- 主要言語
- TypeScript
- スター
- 335
- フォーク
- 23
- 平均マージ
- 1日 8時間
- マージ済み PR（30日）
- 54
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
callstackincubator/react-native-harness のほかの issue
-
On Windows, `report.test.ts`'s unwritable-folder case creates `\dev\null\nope` at the drive root instead of meeting an unwritable folder対応中かも @TheSeydiCharyyev が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
callstackincubator/react-native-harness#301 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
callstackincubator/react-native-harness#296 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
callstackincubator/react-native-harness#128 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 58/100
callstackincubator/react-native-harness#303 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
callstackincubator/react-native-harness#299 ·
メンテナーはふだん 1 日以内に返信
callstackincubator/react-native-harness の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
better-auth/better-auth#12132 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
o8 next debug build aborts on Glass to Dark appearance switch (nil identifier messaged before check)オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
hurttlocker/o8#5112 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
webrecorder/wabac.js#386 ·
-
needs-triage
難易度 1/5 1〜3時間 初心者へのやさしさ 92/100
agent-of-empires/agent-of-empires#5098 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信