Definitely you MUST NOT use the internal objects like
_transports, etc. Those are private members.
A worker is closed when:
worker.close() is called, or
worker.on("died") event is fired.
A router is closed when:
router.close() is called, or
router.on("workerclose") event is fired.
A transport is closed when:
transport.close() is called, or
transport.on("routerclose") event is fired.
A producer is closed when:
producer.close() is called, or
producer.on("transportclose") event is fired.
A consumer is closed when:
consumer.close() is called, or
consumer.on("transportclose") event is fired.
consumer.on("producerclose") event is fired.
When any of those cases happens,
close() action in different objects triggers different events in sub-objects. For instance, calling
transport.close() will trigger “transportclose” event in all producers and consumers in that transport and, hence, also “producerclose” in all consumers (in different transports) associated to those producers in the closed transport.
I really do not understand what you are trying to achieve but you do need to manage your own references to mediasoup objects anyway so you must listen to those events and act according by removing those references from your app memory when appropriate. May be you expect something like
transport.getProducerById(id), etc. so when an API or WebSocket message is received in your Node app you look for the contained
producerId properties, get the corresponding mediasoup object and act on them. I’ve seen that in the past, and people using that approach does zero validation of the message, so any user that knows the
id of a transport or producer not belonging to him can close them or whatever. I strongly think the current API design forces the application to properly manage the mediasoup objects it creates, just that.