Bug Description
The Feishu channel's WebSocket connection panics immediately after initiating the TLS handshake to wss://msg-frontier.feishu.cn. The connection is established (authentication succeeds, WebSocket URL is obtained), but the actual WebSocket upgrade fails because rustls 0.23's CryptoProvider is never installed before the TLS handshake.
Environment
- OpenFang version: v0.5.6 (pre-built binary:
openfang-x86_64-unknown-linux-gnu)
- OS: Ubuntu 24.04 (Docker container:
debian:bookworm-slim)
- Hardware: 2 vCPU / 2GB RAM VPS
- Config:
[channels.feishu]
app_id = "cli_xxxx"
app_secret_env = "FEISHU_APP_SECRET"
mode = "websocket"
Steps to Reproduce
- Configure
[channels.feishu] with valid credentials and mode = "websocket"
- Start OpenFang
- Observe the Feishu WebSocket connection panic in logs
Expected Behavior
Feishu WebSocket connection succeeds, and the bot can receive messages via the long connection.
Actual Behavior
Authentication succeeds, but the WebSocket TLS handshake panics:
2026-04-02T04:33:26.491485Z INFO openfang_channels::feishu: Feishu adapter authenticated as OpenFang
2026-04-02T04:33:26.491571Z INFO openfang_api::channel_bridge: feishu channel bridge started
2026-04-02T04:33:26.491659Z INFO openfang_channels::feishu: Starting Feishu WebSocket mode
2026-04-02T04:33:26.608760Z INFO openfang_channels::feishu: Connecting to Feishu WebSocket endpoint: wss://msg-frontier.feishu.cn/ws/v2?...
thread 'tokio-rt-worker' (9) panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustls-0.23.37/src/crypto/mod.rs:249:14:
Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features are enabled.
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
2026-04-02T04:33:26.775459Z INFO openfang_channels::bridge: Channel adapter feishu stream ended
Root Cause
The Feishu WebSocket client (likely using tokio-tungstenite with rustls) initiates a TLS handshake without first calling CryptoProvider::install_default(). This is required since rustls 0.23+ removed the implicit default crypto provider.
Notably, other parts of OpenFang (e.g., HTTP API calls via reqwest) work fine because they use a different TLS backend. Only the WebSocket connection path is affected.
Suggested Fix
Add the following early in the Feishu channel initialization (or at application startup):
rustls::crypto::ring::default_provider()
.install_default()
.expect("Failed to install rustls crypto provider");Or if using aws-lc-rs:
rustls::crypto::aws_lc_rs::default_provider()
.install_default()
.expect("Failed to install rustls crypto provider");This should be called once before any rustls-backed connection is made.
Workaround
None found. The Feishu channel is completely non-functional in WebSocket mode on v0.5.6. Sending messages works (uses HTTP API), but receiving messages does not (uses WebSocket with rustls).
Bug Description
The Feishu channel's WebSocket connection panics immediately after initiating the TLS handshake to
wss://msg-frontier.feishu.cn. The connection is established (authentication succeeds, WebSocket URL is obtained), but the actual WebSocket upgrade fails becauserustls0.23'sCryptoProvideris never installed before the TLS handshake.Environment
openfang-x86_64-unknown-linux-gnu)debian:bookworm-slim)Steps to Reproduce
[channels.feishu]with valid credentials andmode = "websocket"Expected Behavior
Feishu WebSocket connection succeeds, and the bot can receive messages via the long connection.
Actual Behavior
Authentication succeeds, but the WebSocket TLS handshake panics:
Root Cause
The Feishu WebSocket client (likely using
tokio-tungstenitewithrustls) initiates a TLS handshake without first callingCryptoProvider::install_default(). This is required sincerustls0.23+ removed the implicit default crypto provider.Notably, other parts of OpenFang (e.g., HTTP API calls via
reqwest) work fine because they use a different TLS backend. Only the WebSocket connection path is affected.Suggested Fix
Add the following early in the Feishu channel initialization (or at application startup):
Or if using
aws-lc-rs:This should be called once before any
rustls-backed connection is made.Workaround
None found. The Feishu channel is completely non-functional in WebSocket mode on v0.5.6. Sending messages works (uses HTTP API), but receiving messages does not (uses WebSocket with rustls).