Fix flaky AutocompletePrompt tests under React 19 on CI

[tewson]

Summary

• Fix the Stdin mock to re-emit 'readable' when a listener is added and there's pending data. This mirrors real Node stream behavior and prevents dropped input when data is written before Ink's useInput effect registers its listener — the root cause of the "allows searching with pagination" timeout on slow CI runners.
• Replace sendInputAndWait fixed delays in the "doesn't submit if there are no choices" and "has a loading state" tests with sendInputAndWaitForContent, which deterministically waits for React to confirm the frame still shows expected content after the keypress
• Use a never-resolving search promise in the "has a loading state" test so the loading state persists for the entire test, eliminating races where React 19's batched rendering could resolve the search and transition back to Idle before the ENTER keypress is processed

Test plan

• pnpm --filter @shopify/cli-kit vitest run src/private/node/ui/components/AutocompletePrompt.test.tsx passes locally
• pnpm --filter @shopify/app vitest run src/cli/services/dev/ui/components/Dev.test.tsx src/cli/services/dev/ui/components/DevSessionUI.test.tsx passes locally
• CI passes without flaky failures

🤖 Generated with Claude Code

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	78.81%	14520/18425
🟡	Branches	73.12%	7220/9874
🟡	Functions	79.04%	3695/4675
🟡	Lines	79.14%	13719/17336

Test suite run success

3785 tests passing in 1448 suites.

Report generated by 🧪jest coverage report action from 599317f

[github-actions]

We detected some changes at packages/*/src and there are no updates in the .changeset.
If the changes are user-facing, run pnpm changeset add to track your changes and include them in the next release CHANGELOG.

Caution

DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release.

[binks-code-reviewer]

🤖 Code Review · #projects-dev-ai for questions
React with 👍/👎 or reply — all feedback helps improve the agent.

✅ Complete - 1 findings

📋 History

❌ Failed → ✅ 1 findings

[github-actions]

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/private/node/testing/ui.d.ts

@@ -39,8 +39,12 @@ interface RenderOptions {
 export declare const render: (tree: ReactElement, options?: RenderOptions) => Instance;
 /**
  * Wait for the component to be ready to accept input.
+ *
+ * Listens for Ink's useInput effect to register its 'readable' listener
+ * on stdin via EventEmitter's built-in 'newListener' event — fully
+ * event-driven with no polling or sleeping.
  */
-export declare function waitForInputsToBeReady(): Promise<unknown>;
+export declare function waitForInputsToBeReady(renderInstance?: ReturnType<typeof render>): Promise<void>;
 /**
  * Wait for the last frame to change to anything.
  */

[binks-code-reviewer]

Unbounded setImmediate re-emit on every readable listener addition (can cause hangs/flakes)

The newListener handler schedules setImmediate(() => this.emit('readable')) whenever a 'readable' listener is added and data !== null.

Evidence (current code):

this.on('newListener', (event: string) => {
  if (event === 'readable' && this.data !== null) {
    setImmediate(() => this.emit('readable'))
  }
})

If a consumer adds multiple 'readable' listeners (or re-attaches on rerenders / effect re-runs), you’ll queue a new setImmediate each time while data remains non-null. If the consumer’s readable handler doesn’t drain via .read() (or drains later), this can lead to a large backlog of immediates continually emitting 'readable', potentially starving the event loop and causing test timeouts/flakiness.

Impact:

• User impact: Indirect but real—CI can become flaky/hang in UI tests (Ink/React) that manipulate listeners during renders/effects.
• Infra impact: Increased CPU + longer test runtime; worst case, stuck test workers in CI.
• Scale: Affects any test using this Stdin mock (shared helper) where listeners are added while buffered data exists.