[TheSafo]

What does this PR do?

The http and splunk_hec generators each keep their connection limiter in a process-wide static CONNECTION_SEMAPHORE: OnceCell<Semaphore>. Only the first generator to start can set it. With two http generators in one config, lading panics at startup when the second one is constructed ("failed to set semaphore"). Two splunk_hec generators panic the same way ("semaphore already set").

This PR gives each generator its own Arc<Semaphore>, sized from that generator's parallel_connections. Request tasks hold owned permits from it. On shutdown, http waits only for its own in-flight requests. splunk_hec still does not wait at shutdown, the same as before. A closed semaphore now returns a new SemaphoreClosed error instead of panicking. Configs with a single generator behave the same, and the config schema is unchanged.

Removing the last OnceCell made clippy's non_std_lazy_statics lint flag the Prometheus label regex. That regex now uses std::sync::LazyLock, and the lading crate no longer depends on once_cell.

Motivation

We want to replay a weighted mix of intake payloads in regression experiments. That takes several http generators, each with its own payload and rate, in one lading process.

Additional Notes

New tests in lading/src/generator/http/tests.rs. Each one runs real generators against local hyper servers for under a second of wall-clock time.

• two_generators_enforce_independent_limits: two generators with limits 1 and 3. Each target's peak number of concurrent in-flight requests equals that generator's own limit.
• shutdown_waits_only_on_own_requests: two generators with separate shutdown signals. Each target holds its first request open until the test releases it.
  • After the first generator's signal, it does not exit while its own request is held.
  • Once that request is released, it exits.
  • The second generator keeps sending requests, with its own request still held.
  • With the shutdown acquire_many removed from http.rs, this test fails.

Checks run locally:

• ci/validate passed shellcheck, fmt, check, custom lints and clippy.
• ci/validate then stopped at ci/deny on two advisories: an out-of-bounds write in aes::unwrap_key, and pin-utils being unmaintained. This PR adds neither crate; its only Cargo.lock change removes once_cell.
• I ran the steps ci/validate skipped after that failure: ci/config-validation, ci/test (578 of 578 tests passed) and ci/loom lading-signal (passed). Kani was not run.
• I ran the lading binary for 10s with two http generators (limits 1 and 4) posting to lading's own http blackhole on a local port. Both generators sent requests, and lading exited 0 without panicking.

No other generators or blackholes use a process-global semaphore or OnceCell.

[datadog-prod-us1-5]

✨ Unblock PR with BitsAI

❌ Errors

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 2 Pipeline jobs failed

Continuous integration | cargo-deny — 🔧 Needs a code fix, caused by this PR

View more details · View in GitHub Actions

Security Audit | security_audit

View more details · View in GitHub Actions

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 15de4d7 | Docs | View more details | Give us feedback!}