Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Bug] Android: Apps page can reject a valid workspace 200 ("no response was produced")

オープン 初心者向け
  • 何か問題がありますか？
#215 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
66/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
react-native, typescript
領域
mobile

調査の方向性

まず、Android の workspace リクエスト経路と @copilotkit/react-native の streaming-fetch 実装を読みます。issue では、upstream の報告 CopilotKit/CopilotKit#8099 と、失敗している readyState の安全性チェックが特定されています。記載された Expo と React Native のバージョンを使い、Android で Apps を開くか更新して再現します。有効な HTTP 200 応答で workspace が安定して読み込まれれば完了です。issue では依存関係の更新またはパッケージへのパッチが提案されています。

索引モデルが issue の本文から書いたものです。

説明

What happened?

On Android, opening Apps (or refreshing the workspace) intermittently shows a red error instead of the app list:

TypeError: Network request to https://<app-host>/api/workspace completed with status 200 but no response was produced. This may indicate a CORS failure, DNS error, or React Native networking issue.

The server did return the workspace JSON: the access log shows GET /api/workspace 200 527 with user agent okhttp/4.12.0. Web and iOS are fine; Android hits it intermittently.

Expected: Apps loads the workspace.
Actual: the request rejects even though the server returned 200.

Steps to reproduce
  1. Build the Android app from main with Expo SDK 54 / RN 0.81.5 / @copilotkit/[email protected].
  2. Sign in with a live workspace access key.
  3. Open Apps or refresh the workspace a few times (the failure is intermittent).
  4. The red TypeError appears instead of the app list.
Commit or release

main at 2026-10-28 (app.json version 0.1.0, versionCode 1).

Platform

Android

Environment and safe logs
  • Android 14/15 emulator, x86_64, Hermes, new architecture
  • OkHttp 4.12.0
  • @copilotkit/[email protected]
  • Server access log: GET /api/workspace 200 527 "okhttp/4.12.0"
  • No credentials or private data included
Root cause / upstream issue

This is a downstream manifestation of a bug in @copilotkit/react-native's XHR streaming-fetch polyfill. On Android, XHR can jump from readyState 1 to 4; the safety net in src/streaming-fetch.ts runs before the Response object is constructed and treats a valid 200 as "no response produced".

Upstream report with code, reproduction and a one-line fix: CopilotKit/CopilotKit#8099.

Workaround

Patch the installed package's streaming-fetch (source + dist/streaming-fetch-*.mjs / .cjs):

- if (readyState === 4 && !settled && !resp) {
+ if (readyState === 4 && !settled && !resp && xhrStatus === 0) {

Then rebuild the Android JS bundle. We applied this locally and Apps loads reliably on Android 15.

A patch-package/postinstall patch or a dependency bump once upstream is fixed would make the APK robust for other Android users.

主要言語
TypeScript
スター
5.6k
フォーク
797
平均マージ
4日 8時間
マージ済み PR（30日）
67

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CopilotKit/openmuse のほかの issue

CopilotKit/openmuse の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。