Summary
When a YAML config is posted via POST /config, the DNS override (resolveTargetAddr) and TLS settings (skipTlsVerify) are correctly parsed and applied to the main HTTP client — but scenario workers silently discard those settings and make requests with a plain default client.
Root Cause
run_scenario_worker in src/worker.rs accepted a pre-configured reqwest::Client as its first parameter but ignored it entirely (named _client). Instead, it created a new bare reqwest::Client::builder() inside the loop on every scenario iteration:
```rust
pub async fn run_scenario_worker(
client: reqwest::Client, // Ignored - we create per-execution clients
...
) {
loop {
// New default client — no DNS override, no TLS settings
let client = reqwest::Client::builder()
.cookie_store(true)
.timeout(std::time::Duration::from_secs(30))
.build()
.unwrap_or_else(|| reqwest::Client::new());
```
This meant that any resolveTargetAddr or skipTlsVerify set via POST /config was applied to startup diagnostics but never used for actual scenario requests, causing all requests to fail with connection errors when the target is only reachable via the DNS override.
Symptoms
- All scenario requests fail with
NetworkError / connection error immediately after posting a config
- Prometheus metrics show
network_error counter rising
curl to the target succeeds from the same host- DNS override log lines appear in docker logs (confirming the main client was configured correctly)
- Adding
skipTlsVerify: true does not help
Fix (PR #113)
- Added
skip_tls_verify: bool and resolve_target_addr: Option<String> to ScenarioWorkerConfig
- Removed the unused
_client parameter from run_scenario_worker
- Build a single properly-configured client (DNS override + TLS + cookie store) once per worker before the loop using
build_client
- Added
cookie_store: bool to ClientConfig so the worker client can request cookie jar support through the standard builder
Affected versions
All versions that support POST /config with scenario workers (standalone mode, Issue #82 onwards).
Summary
When a YAML config is posted via
POST /config, the DNS override (resolveTargetAddr) and TLS settings (skipTlsVerify) are correctly parsed and applied to the main HTTP client — but scenario workers silently discard those settings and make requests with a plain default client.Root Cause
run_scenario_workerinsrc/worker.rsaccepted a pre-configuredreqwest::Clientas its first parameter but ignored it entirely (named_client). Instead, it created a new barereqwest::Client::builder()inside the loop on every scenario iteration:```rust
pub async fn run_scenario_worker(
client: reqwest::Client, // Ignored - we create per-execution clients
...
) {
loop {
// New default client — no DNS override, no TLS settings
let client = reqwest::Client::builder()
.cookie_store(true)
.timeout(std::time::Duration::from_secs(30))
.build()
.unwrap_or_else(|| reqwest::Client::new());
```
This meant that any
resolveTargetAddrorskipTlsVerifyset viaPOST /configwas applied to startup diagnostics but never used for actual scenario requests, causing all requests to fail with connection errors when the target is only reachable via the DNS override.Symptoms
NetworkError/connection errorimmediately after posting a confignetwork_errorcounter risingcurlto the target succeeds from the same hostskipTlsVerify: truedoes not helpFix (PR #113)
skip_tls_verify: boolandresolve_target_addr: Option<String>toScenarioWorkerConfig_clientparameter fromrun_scenario_workerbuild_clientcookie_store: booltoClientConfigso the worker client can request cookie jar support through the standard builderAffected versions
All versions that support
POST /configwith scenario workers (standalone mode, Issue #82 onwards).