mlevkov opened a new issue, #4101: URL: https://github.com/apache/iggy/issues/4101
## What happens `SinkManager::start_connector` in `core/connectors/runtime/src/manager/sink.rs` records the new plugin id on `SinkDetails` only after `setup_sink_consumers` has returned. A failure between `init_sink` and that record leaves the plugin holding an instance whose id nothing outside it knows, and `stop_connector` closes whatever `details.info.id` still holds, which is the previous instance. This is the same window #4062 described on the source path, one manager over. ## Why it is narrower than the source case Sink consume tasks exit when the `watch::Sender` in `SinkDetails` drops, so the runtime half of the leak cleans itself up. Only the FFI half is stranded: the plugin keeps an open instance that nothing will close for the life of the process. That is why this needs the guard and not the second half of the #4064 fix. The source path also had to move the id record under the same lock as the task spawn, because `SOURCE_SENDERS` is a process global that no drop can reach. The sink has no equivalent. ## Fix Use the same `SourceInstanceGuard` shape #4064 added, armed once `init_sink` succeeds and disarmed once the id is recorded on `SinkDetails`. ## Provenance Raised by @hubcio in review on #4064, out of that PR's diff and explicitly non-blocking for it. Filed separately so it does not disappear when #4064 merges. ### Contribution - [x] I'm willing to submit a pull request to fix this bug -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
