c-bridge: drop worker Arc clone before waking lang to fix finalize_shutdown race

[EdmondDantes]

Problem

temporal_core_worker_finalize_shutdown takes sole ownership of the worker via Arc::try_unwrap(worker.worker.take().unwrap()):

let core_worker = match Arc::try_unwrap(worker.worker.take().unwrap()) {
    Ok(core_worker) => core_worker,
    Err(arc) => { /* "Cannot finalize, expected 1 reference, got {N}" */ return; }
};
core_worker.finalize_shutdown().await;

But every poll/complete/validate FFI fn clones that Arc into a spawned Tokio task and drops the clone only at task-scope end — after invoking the completion callback that wakes the foreign (lang) thread:

let core_worker = worker.worker.as_ref().unwrap().clone();
worker.runtime.core.tokio_handle().spawn(async move {
    let (success, fail) = match core_worker.poll_workflow_activation().await { ... };
    unsafe { callback(user_data.into(), success, fail); } // wakes lang...
}); // ...core_worker dropped only HERE, after the wake

So when lang reacts to a poll returning shutdown by calling finalize_shutdown, the poll task's clone may still be alive (strong_count == 2), try_unwrap returns Err, and finalize fails. Because the worker is already take()n out of the Option, it is spent and the call cannot be retried. This is timing-dependent: it surfaces intermittently under load (e.g. CI), not on a quiet machine.

Fix

Drop the worker clone as soon as the await result is in hand and before invoking the callback (notify-after-release ordering), in all seven spawning fns (validate, poll_workflow_activation, poll_activity_task, poll_nexus_task, complete_workflow_activation, complete_activity_task, complete_nexus_task). The woken lang thread is then guaranteed to observe sole ownership.

Pure reordering — no added synchronization, no behavior change on the success path. +28 −0, one file.

Validation

Found and fixed while building a PHP SDK on this C bridge. Reproduced as intermittent finalize_shutdown failures on CI; with this change the worker create/poll/shutdown lifecycle and the full workflow/activity/cancellation integration suite pass deterministically against a live dev server.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Edmond seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Sushisource]

This makes sense. Thanks for the fix!

My only suggestion would be I think we can drop the repetitive comment in each spot. Maybe we can have just one instance of it somewhere generic?

while building a PHP SDK on this C bridge

Would be curious to hear more about this! We do have https://github.com/temporalio/sdk-php/ which you may know was initially built before Core existed on top of Go

[EdmondDantes]

This makes sense. Thanks for the fix!

My only suggestion would be I think we can drop the repetitive comment in each spot. Maybe we can have just one instance of it somewhere generic?

while building a PHP SDK on this C bridge

Would be curious to hear more about this! We do have https://github.com/temporalio/sdk-php/ which you may know was initially built before Core existed on top of Go

Yes, I'm familiar with it. I was asked to create a clone that would work without Temporal. In principle, I could adapt that project to run on regular PHP-core.I mean the core/runtime without TrueAsync.

[Sushisource]

This makes sense. Thanks for the fix!
My only suggestion would be I think we can drop the repetitive comment in each spot. Maybe we can have just one instance of it somewhere generic?

while building a PHP SDK on this C bridge

Would be curious to hear more about this! We do have https://github.com/temporalio/sdk-php/ which you may know was initially built before Core existed on top of Go

Yes, I'm familiar with it. I was asked to create a clone that would work without Temporal. In principle, I could adapt that project to run on regular PHP-core.I mean the core/runtime without TrueAsync.

Interesting. Having PHP to run on top of our Core SDK would be nice to have, but would constitute a V2 of the SDK essentially. Have you got in touch with the folks who work on the existing PHP SDK? They might be interested in your work.

@wolfy-j and @xepozz FYI

Anyway, happy to merge this if we drop the repetitive comments.