Skip to content

[Investigate] stream_connect_timeout_secs config PR: lightweight client negotiate test fails — suspected coupling to config change #2694

Description

@1688mengdie

Background / Phenomenon

A Pull Request adding stream_connect_timeout_secs to AIConfig (mirroring the existing stream_ttft_timeout_secs pattern, Option default Some(10), propagates to StreamOptions.connect_timeout: Option) shows the lightweight_client_negotiates_with_the_production_server test failing with missing advertised method session/reloadContext (agent_kernel.rs:1101) on the fork's CI.

The change itself is correct in behavior:

  • Default Some(10) preserves existing 10s connect timeout
  • None = infinite wait
  • Mirrors established stream_ttft_timeout_secs pattern
  • Does not touch �gent_kernel.rs, capability registration, or context_reload port injection

Evidence: Same Environment Comparison

Fork CI environment (BitFun-SIG/taiji-plugin-library):

Branch Commit SHA CI Run ID Test Result Notes
Clean (no G2 change) �39d03c4a 33327034872 success Test passes
G2 branch (with change) 9c44bb9 33315937114 failure ≥3 runs consistently fail
G2 branch (re-run) 9c44bb9 33324900783 failure Consistent failure

Conclusion: The change deterministically triggers the failure in the same environment. Fork clean baseline passes; G2 branch fails consistently.

Investigation Summary (No Direct Causal Chain Found)

After 6 rounds of static analysis and hypothesis testing:

  1. Direct causality: No direct/indirect causal chain found — G2 change does not touch �gent_kernel.rs, capability registration, or context_reload port injection.
  2. Struct layout/LTO hypotheses: Examined AIConfig struct layout, serialization, LTO, and indirect-runtime-construction hypotheses — all inconclusive.
  3. Behavioral restoration: Restoring old connect_timeout=10s hardcoded behavior did not fix the failure.
  4. Test fragility suspicion: Suspect fragile coupling between this specific test (lightweight_client_negotiates_with_the_production_server) and the config/client changes.

The test failure message (missing advertised method session/reloadContext) suggests the agent kernel is not advertising expected methods after the config change, despite no code touching the kernel directly.

Request for Assistance

Could a maintainer help locate why the stream_connect_timeout_secs config change causes lightweight_client_negotiates_with_the_production_server to stop advertising session/reloadContext?

Specific questions:

  1. Is there an unexpected interaction between StreamOptions.connect_timeout: Option and agent kernel method registration?
  2. Could the config change affect runtime construction paths that impact capability advertisement?
  3. Are there any known fragile couplings between StreamOptions and �gent_kernel.rs that we might have missed?

Testing status:

  • Cargo check: ✅ pass
  • Type-check: ✅ pass
  • i18n:audit: ✅ pass
  • Issue: CI single-test red on fork only (same environment as upstream main)

Note: This PR was created following upstream patterns and maintains backward compatibility (default Some(10)). The change is functionally correct but appears to trigger a test failure that may indicate a deeper coupling issue.


Test: Light test (compile pass / type-check / i18n:audit 0 warning)
AI: Semantic quality optimization rewrite (mirroring ttft chain pattern, aligned with upstream Duration style)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions