Question 1

Rustのテストをコンパイルする際に発生するエラー E0599「no method named `start_paused` found for struct `tokio::runtime::Builder`」を修正するにはどうすればよいですか？

Accepted Answer

`#[tokio::test(start_paused = true)]` 属性には tokio の `test-util` feature が必要ですが、これはデフォルトでは有効になっていません。修正方法: クレートの Cargo.toml の `[dev-dependencies]` に `test-util` feature を有効にした tokio を追加してください。

```toml
[dev-dependencies]
tokio = { version = "1", features = ["test-util"] }
```

tokio がすでに通常の依存関係として存在している場合でもこの方法は有効です。dev-dependencies で有効にした feature はテストターゲットのコンパイル時に適用されるためです。あるいは、ワークスペースレベルの tokio エントリで `test-util` を有効にする方法もあります。追加後は `cargo test -p <crate> --lib --no-run` で確認してください。テストターゲットがコンパイルされ、時間を一時停止したテストが実行されるようになります。

Question 2

Rust クレートをスタンドアロンでビルドする際に発生する "cannot find `select` in `tokio`" エラー (E0433) を修正するには？

Accepted Answer

このエラーは、`tokio::select!` が tokio の `macros` フィーチャーを必要としているにもかかわらず、それがクレートの `[dependencies]` に含まれていないために発生します。ワークスペースビルドでは、feature unification によって他のワークスペースメンバーや dev-dependencies 経由で `macros` が有効になるため、この問題は見過ごされがちです。修正方法: クレートの Cargo.toml で tokio の features に `macros` を追加してください：

```toml
[dependencies]
tokio = { version = "1", features = ["sync", "time", "macros"] }
```

その後、`cargo build -p <crate-name>` で再ビルドします。jcode に関しては、この問題は `jcode-provider-core` クレートに対する PR #1862 で修正されました。

Question 3

なぜ jcode --provider-profile が anthropic-compatible プロファイルで /chat/completions を呼び出し、404 を返すのですか？

Accepted Answer

これは jcode v0.89.0 のバグです。--provider-profile が ProviderChoice::OpenaiCompatible を無条件に設定し、プロファイルの anthropic-compatible タイプを上書きします。回避策は、モデルプレフィックスを付けて jcode --model fcc-anthropic:claude-3-5-sonnet run "hello" を実行するか、default_provider に頼って jcode run "hello" を実行することです。src/cli/dispatch.rs でのソース修正では、プロファイルタイプからプロバイダーを選択します。プロファイルタイプが AnthropicCompatible の場合は ProviderChoice::AnthropicApi を設定し、そうでなければ ProviderChoice::OpenaiCompatible を使用します。

Question 4

どうすれば、cargo check が失敗しても成功を報告する Bash CI 警告ゲートを修正できますか？

Accepted Answer

この失敗は cargo check ... | grep -c '^warning:' || true によって引き起こされます。|| true は grep の一致なしステータスと Cargo の失敗終了コードの両方を覆い隠すため、警告が 0 件のコンパイラエラーが current=0 になり通過する可能性があります。

Cargo の出力を先にキャプチャし、Cargo の終了ステータスを保持し、grep の終了コード 1 のみを警告 0 件として扱うことで修正してください:

set -euo pipefail

cargo_status=0
output=$(CARGO_TERM_COLOR=never cargo check -q 2>&1) || cargo_status=$?

if (( cargo_status != 0 )); then
  printf '%s
' "$output"
  printf 'cargo check failed with exit status %s
' "$cargo_status" >&2
  exit "$cargo_status"
fi

grep_status=0
warning_count=$(printf '%s
' "$output" | grep -c '^warning:') || grep_status=$?

if (( grep_status == 1 )); then
  warning_count=0
elif (( grep_status > 1 )); then
  exit "$grep_status"
fi

if (( warning_count > baseline )); then
  printf '%s
' "$output"
  printf 'Warning budget exceeded: current=%s baseline=%s
' \
    "$warning_count" "$baseline" >&2
  exit 1
fi

printf 'Warning budget OK: current=%s baseline=%s
' \
  "$warning_count" "$baseline"

また、コンパイル失敗時または予算違反時に、キャプチャした診断を出力してください。ベースラインを引き上げるのではなく、実際の警告を修正してください。テスト専用のインポートやヘルパーについては、#[cfg(test)] でゲートしてください。成功したチェック、予算未満/予算ちょうど/予算超過の警告、警告あり/なしのコンパイラ失敗、Cargo が見つからない場合の fake-Cargo コントラクトテストを追加してください。リポジトリの修正は PR #1771 に含まれています。

Question 5

jcodeでOpenAI互換プロバイダー（glm-coding、OpenRouter、DeepSeek）を使用する際の「429 Too Many Requests」レート制限エラーを修正する方法

Accepted Answer

古いバージョンの jcode では、リトライ回数が3回にハードコードされており(バックオフは約1秒/2秒/4秒)、約9秒で失敗していました。リトライを設定可能にするコミット be1e855cb を含むビルドにアップグレードしてください。デフォルトは `max_retries = 8` および `retry_backoff_cap_secs = 30` になりました(約5分間リトライします)。スロットリングが激しい場合は、`config.toml` 内の該当プロバイダーのセクションでこれらの値を引き上げてください:

```toml
[providers.glm-coding]
type = "openai-compatible"
base_url = "https://open.bigmodel.cn/api/coding/paas/v4"
max_retries = 30
retry_backoff_cap_secs = 60
```

または、環境変数で上書きします: `JCODE_MAX_RETRIES=30` および `JCODE_RETRY_BACKOFF_CAP_SECS=60`。サーバーの `Retry-After` ヘッダーは引き続き尊重されますが、設定されたバックオフの上限で制限されます。1つのエンドポイントで複数の swarm エージェントを同時に実行する場合は、より大きな値(例: 約20分間リトライする場合は 30/60)を推奨します。

jcode

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト