chore(🐙): add runtime reload lifecycle diagnostic

[NikitaDudin]

moved lifecycle diagnostic from PR #427

[wcandillon]

can you move it to this sublist?

[wcandillon]

love it! Thank you for this. Now if I try this example as is, it will crash?

[NikitaDudin]

No, this results in loss of context on reboot, rn-webgl devices simply stop working (no adapter or no device).

[wcandillon]

love it, let me try it now

[wcandillon]

Can you explain me the folow to reproduce the issue, I wasn't able to do it? Is this Android/iOS physical devices?

[NikitaDudin]

The original issue was reproducible in our app on Expo SDK 55 with react-native-webgpu 0.5.9. After expo-updates reloadAsync(), WebGPU became unavailable — we could no longer acquire an adapter or device.
I implemented a custom local patch at the time and kept porting it as we upgraded react-native-webgpu from version to version. Since the patch had remained part of our codebase, I eventually decided to upstream it as #427.
However, after retesting the actual expo-updates reloadAsync() flow in a release build on a physical iOS device with Expo SDK 57, I can no longer reproduce the issue. I tested react-native-webgpu 0.5.11, 0.6.0, and 0.6.1; all of them successfully restore WebGPU after reload, and the adapter/device remain available.
Since 0.5.11 predates #426 and also works correctly with Expo SDK 57, the original trigger may have been resolved by changes in the Expo/React Native runtime lifecycle rather than by #426 alone.
Given the size of #427 and the lack of a current reproduction, this work may now be unnecessary. I don’t think we should merge such a broad lifecycle change without a failing baseline. I’m happy to close #427 as no longer reproducible while keeping the smaller diagnostics PR if you still find it useful. If the issue returns, I can provide an A/B reproduction and extract a smaller targeted fix.

[wcandillon]

if apps/example would use expo instead RNTA would that help with reproducing the issue on our side?

[NikitaDudin]

I think, no at this moment. I checked on my app and for now it works fine on RN0.86+Expo SDK 57.

[NikitaDudin]

There is still one robustness scenario from #427 that may be worth preserving: a reload can happen while asynchronous WebGPU work is still in flight — for example during createComputePipelineAsync(), mapAsync(), queue.onSubmittedWorkDone(), or while device.lost and error listeners are registered.
Native Dawn work may outlive the JavaScript runtime that initiated it. The GPU work itself does not necessarily need to be interrupted, but a late completion must not settle a Promise or invoke a listener on a destroyed JSI runtime.
#426 hardens the surface lifecycle, but it does not explicitly invalidate all runtime-owned asynchronous work during teardown. #427 addresses this class of lifetime races. I don’t think this alone justifies merging the entire PR as-is, but if you are interested, I can extract the async cancellation/runtime invalidation part into a smaller focused hardening PR with a stress test.