Context
runtime_param_schema (wrapper.rs:776) and get_source_config (wrapper.rs:1250) remain synchronous/unguarded outliers — they are called on the async side without timeout, catch_unwind, or routing through the worker thread.
What needs to happen
- Route both calls through the worker thread's
WorkerRequest channel (add new variants)
- Apply the same
catch_unwind + timeout pattern used for other FFI calls
- Handle the chicken-and-egg problem:
get_source_config is called before the tick loop starts, and runtime_param_schema is called during node registration (before the worker exists)
Why not now
This was identified during the PR 3 (worker thread) review. Both calls happen at low frequency (once per instance creation / start), so the risk is low. The refactor requires rethinking the call timing vs. worker lifecycle, which is better handled as a separate change.
References
Context
runtime_param_schema(wrapper.rs:776) andget_source_config(wrapper.rs:1250) remain synchronous/unguarded outliers — they are called on the async side without timeout, catch_unwind, or routing through the worker thread.What needs to happen
WorkerRequestchannel (add new variants)catch_unwind+ timeout pattern used for other FFI callsget_source_configis called before the tick loop starts, andruntime_param_schemais called during node registration (before the worker exists)Why not now
This was identified during the PR 3 (worker thread) review. Both calls happen at low frequency (once per instance creation / start), so the risk is low. The refactor requires rethinking the call timing vs. worker lifecycle, which is better handled as a separate change.
References