[elhoim]

BLUF — Documents that MispClientBlocking panics when used from inside an async runtime.

• Problem — MispClientBlocking in src/client_blocking.rs owns a tokio::runtime::Runtime and calls block_on in every method, so calling or dropping it inside an existing runtime panics with "Cannot start a runtime from within a runtime". reqwest::blocking documents this; this did not.
• Fix — Adds a # Panics section to the MispClientBlocking struct doc and to the client_blocking module doc in src/lib.rs, mirroring reqwest::blocking's wording.
• Effect — Users meet the constraint in rustdoc rather than as a runtime panic; docs only, no behavior change.
• CI — Red from a repo-level CI bug (ubuntu-22.04 runner lacks php8.3 mod_php; test_event_crud_lifecycle races the publish worker), fixed in unmerged PR fix: [ci] Run integration tests on ubuntu-24.04 to match php8.3 #53 and unrelated to this change.

Finding

MispClientBlocking panics inside an async runtime with no warning
It owns a tokio Runtime; any method call from inside an existing runtime panics with 'Cannot start a runtime from within a runtime', and dropping it in async context panics too. reqwest::blocking documents this; this does not.

Change

Confirmed MispClientBlocking (src/client_blocking.rs) owns a dedicated tokio::runtime::Runtime and every method calls Runtime::block_on (e.g. line 167 onward), with no custom Drop impl. tokio documents that block_on panics with "Cannot start a runtime from within a runtime" when invoked from a thread already inside an async execution context, and that dropping a Runtime there panics too, matching the finding exactly. Added a "# Panics" doc section to the MispClientBlocking struct in client_blocking.rs and to the client_blocking module doc in lib.rs, mirroring reqwest::blocking's documented wording and cross-referencing it. Docs-only change, no code/behavior modified.

Upstream evidence

Not applicable to MISP core / PyMISP: this finding concerns Rust async-runtime semantics (tokio's block_on/Drop panic behavior), not MISP wire protocol or controller/model behavior, so the pinned MISP controller and PyMISP sources contain no relevant evidence either way. The finding itself names the correct reference to mirror: reqwest::blocking (https://docs.rs/reqwest/latest/reqwest/blocking/index.html), which documents the identical "cannot call/drop from within a runtime" constraint for its own Runtime-wrapping blocking client; the wording added here mirrors that documented behavior.

Verified against MISP core 843b6744 and PyMISP e7debb4f.

Tests

No runnable test: this is a docs/CI-only change, or the affected test requires a live MISP instance.

Caveats

Pure documentation change (added "# Panics" sections to MispClientBlocking's struct doc and the client_blocking module doc in lib.rs). No code behavior changed, no test suite run (per task instructions, cargo build/test/clippy were not invoked; only cargo fmt was run). The upstream MISP/PyMISP pinned references are not applicable to this finding since it is a Rust-runtime API-misuse concern, not a MISP wire-protocol issue.

---

Verified locally: cargo fmt --check, cargo clippy --all-targets --all-features -- -D warnings, cargo test --all-features --lib, --test integration_tests --no-run, and cargo check --examples, each in an isolated target directory.

🤖 Generated with Claude Code