Feature request: apply streamingProfile (ttft/tps/jitter) to non-streaming responses too
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 45/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- api
調査の方向性
Start by finding where streamingProfile and latency are applied on the stream: true path, then compare them with the non-streaming branch that writes the fixture response immediately. The issue names four handlers (OpenAI-shaped, Claude Messages, Bedrock invoke, Bedrock invoke-with-response-stream) and the recorded-timings replay path. Done means non-streaming responses wait ttft + length/tps with jitter, or the maintainers have agreed on an opt-in flag first.
索引モデルが issue の本文から書いたものです。
説明
Right now `streamingProfile` (ttft/tps/jitter) only kicks in when the request has `stream: true`. For a non-streaming request, the fixture response gets written back immediately regardless of what `streamingProfile`/`latency` is set to - checked this across the OpenAI-shaped handler, the Claude Messages handler, and the Bedrock invoke/invoke-with-response-stream handlers, same pattern in all of them.
This matters for load/perf testing agent setups where a lot of the real traffic is non-streaming on purpose - sub-agent calls, tool-chain orchestration, guardrail/classifier calls, anything that isn't a user-facing chat UI. Right now mocking those gives zero latency, which throws off any load test that's trying to reproduce realistic timing/compounding across a call tree.
Would be great if `ttft`/`tps`/`jitter` (and the recorded-timings replay path) applied the same delay math to the non-streaming branch - obviously without the per-chunk pacing, just the equivalent total delay (ttft + completion_length/tps) before writing the response.
Happy to be told this is intentional (e.g. to keep default test runs fast) but if so maybe worth a flag to opt in, since right now there's no way to get non-streaming latency simulation at all.
- 主要言語
- TypeScript
- スター
- 979
- フォーク
- 84
- 平均マージ
- 1日 2時間
- マージ済み PR（30日）
- 77
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
CopilotKit/aimock のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 58/100
CopilotKit/aimock#549 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Dependency Dashboardオープン
難易度 5/5 1週間以上 初心者へのやさしさ 10/100
CopilotKit/aimock#289 ·
メンテナーはふだん 1 日以内に返信
CopilotKit/aimock の issue をすべて見る
似ている issue
-
bug hacktoberfest help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
libredb/libredb-studio#1941 ·
メンテナーはふだん 1 日以内に返信
-
chore other
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
alastair-smith/card-games#308 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
paperclipai/paperclip#17379 ·
メンテナーはふだん 1 日以内に返信
-
[good first issue, hacktoberfest] 🏯 Hacktoberfest Task - Add new Anime Quote 626 (good-first-issue)オープンcommunity first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
難易度 1/5 1時間未満 初心者へのやさしさ 76/100
lingdojo/kana-dojo#33040 · コメント 1 件 · リアクション 5 件 ·
メンテナーはふだん 1 日以内に返信
-
bug mobile ui
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信