Question 1

Content-LengthとTransfer-Encoding: chunkedの両方が送信されることが原因で、Envoy/Istio越しにTypesenseのフォロワーからリーダーへの書き込みが502で失敗する問題を修正するにはどうすればよいですか？

Accepted Answer

これは Typesense v26.0 から v30.2 に影響します。`src/http_client.cpp` では、フォロワーからリーダーへの転送処理で `Content-Length` が手動で追加されますが、libcurl は `CURLOPT_POSTFIELDSIZE` を指定せずに `CURLOPT_POST` と `CURLOPT_READFUNCTION` を使用するため、libcurl が `Transfer-Encoding: chunked` も追加してしまいます。RFC 7230 では両方のヘッダーの併用が禁止されているため、Envoy/Istio、nginx、HAProxy などの厳格なプロキシはこのリクエストを HTTP 400 で拒否し、クライアントには 502 として見えます。

恒久対策: 手動での `content-length` ヘッダー追加を削除し、リクエストボディのサイズを明示的に設定して、libcurl が `Content-Length` のみを生成するようにします:

```cpp
// Remove the manual header append, e.g.:
// std::string content_length_header =
//     "content-length: " + std::to_string(req_res->req->_req->content_length);
// chunk = curl_slist_append(chunk, content_length_header.c_str());

// Add:
curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE,
                 (long)req_res->req->_req->content_length);
```

パッチを適用した後、Typesense を再ビルドしてください。

一時的な Istio/Envoy の回避策: フォロワーからリーダーへのトラフィックに使用される内部の headless Service を TCP として設定し、Envoy が HTTP インスペクションをスキップするようにします:

```yaml
apiVersion: v1
kind: Service
metadata:
  name: typesense-headless
spec:
  clusterIP: None
  ports:
    - name: tcp-typesense
      port: 8108
      targetPort: 8108
      appProtocol: tcp
```

Service の変更を適用し、Typesense Pod を再起動またはロールアウトしてください。現在のリーダーに直接書き込みを送信することでも転送パスを回避できますが、厳格な HTTP プロキシ経由でフォロワーへの書き込みを確実に行うには、コードパッチまたは TCP バイパスが必要です。

Question 2

async_reference エイリアスを使った JOIN を使用している場合に、再起動後に発生する Typesense エラー "Failed to join ... No reference field found" を解決するにはどうすればよいですか？

Accepted Answer

Typesenseをv31.0.rc6以降にアップグレードしてください。このリリースでは、起動時に参照元のコレクションがエイリアスされたターゲットコレクションより先にロードされる場合の、エイリアスベースの`async_reference` JOIN解決の問題を修正しています。

Dockerを使用している場合は、イメージを更新してください。例:

```bash
docker pull typesense/typesense:31.0.rc6
```

その後、Typesenseを再起動し、失敗していた`filter_by` JOINクエリを再実行してください:

```text
filter_by=$bookings(x:=`11`)
```

この問題は、エイリアスのスワップがなくても再起動時に影響し、v30.2で`--num-collections-parallel-load=1`を指定した場合に再現が確認されています。

Question 3

TypesenseでCloudflare Workers AI streamingを使っている際に発生する'type must be string, but is null'エラーの修正方法

Accepted Answer

このエラーは、Cloudflare Workers AIを使用した会話型検索でTypesense v30.1を使用する際に発生します。Cloudflareの最後のSSEチャンクには"response": nullが含まれており、JSON型エラーを引き起こします。この問題が修正されたバージョン（v30.2+など）のTypesenseにアップグレードしてください。回避策として、conversation_model.cppの978行目で、responseフィールドにアクセスする前にnullチェックを追加します：if (chunk["response"].is_null()) continue;。これにより、使用のみのチャンクをスキップし、ストリーミング応答が正しく処理されるようになります。

Question 4

DNS名を使用してクラスターを再起動する際に発生する Typesense Raft の「Unable to resolve host」および「Fail to parse nodes」エラーの修正方法

Accepted Answer

影響を受ける Typesense v30.x リリースでは、`--nodes` 内のすべてのピアエントリが、起動時またはピア更新時に名前解決できる必要があります。DNS レコードが1つでも存在しない場合(たとえば、停止したコンテナや削除された Kubernetes Pod が再登録されていない場合)、起動が失敗したり、リーダーが `Check failed: !entry->peers->empty()` で中断したりする可能性があります。

確実な回避策は、nodes ファイルで DNS 名の代わりに安定した生の IP アドレスを使用することです。

```text
10.0.0.1:8107:8108,10.0.0.2:8107:8108,10.0.0.3:8107:8108
```

手順:
1. 影響を受ける Typesense ノードを停止します。
2. `--nodes` に渡すファイル内の DNS ベースのエントリを、各ノードの到達可能な IP に置き換えます。
3. `--peering-address` はノード自身の到達可能な IP に設定したままにします。
4. ノードを再起動し、Raft クォーラムが復元されたことを確認します。

AWS CloudMap、Docker DNS、または Kubernetes headless Service を使用している場合は、影響を受けるバージョンでノードを起動する前に、すべてのピア DNS レコードが存在していることを確認してください。アップストリームの修正では、DNS のリトライが追加され、DNS 障害時に永続化された状態を持つノードの再起動が許可され、DNS 名前解決が失敗した場合にピア更新がスキップされます。これらの修正を含むリリースが利用可能になったら、アップグレードしてください。

typesense

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト