Make swift event sink less fragile

[rjrjr]

Swift event sink throws if it receives a late action of a type that doesn't match the one that it was created with. This is complex to maintain and kind of confusing. Instead we should effectively maintain a single sink per workflow lifetime.

Kotlin will make a similar change, #741 .

[AquaGeek]

I spent some time looking at this. I might need to sync with @rjrjr to get more context behind this issue, but since @davidapgar's changes in a4927f8 the ReusableSinks that get created live as long as they are still needed (due to being created/reused in the render call). For sinks that get created every render call this effectively means their lifetime is tied to the associated WorkflowNode.

We do, however, move the various EventPipes though their states in the implementation of SubtreeManager.render. This can cause EventPipe.handle(event:) to fatalError if events are fired when they shouldn't (e.g. while render is running). Maybe that's what this issue is about?

[rjrjr]

I was basically taking dictation when I logged this, so I can't shed much more light. The fatalError you describe is interesting. I can't tell whether it's reasonable or racy — seems like a good thing if we're able to assume single threading.

Anyway, if there is still a real problem in this area, I suspect it will be mooted by the work for #1021.

[zach-klippenstein]

I am pretty sure this issue was filed specifically about sinks erroring when used after the workflow that owns them stops being rendered. If that no longer happens, then we can close it. Kotlin has had this behavior now for some time as well.

[AquaGeek]

That can theoretically still happen, but I think due to changes between when this issue was created and now it's much less likely. Closing this — we can reopen if needed.