fireStateAtPath crashes on Android

[dan-phantom]

Description

The app (expo client) crashes when trying to use fireStateAtPath

Provide a Repro

The issue seems to be that it doesn't find the StateMachine in the native side. Sadly I cannot provide a riv file but it works on both iOS and web - with fireStateAtPath - so the riv file is fine.

fireState also works fine

        const fireStateOrfireStateAtPath = (stateName: string) => {
          if (stateName.includes("/")) {
            const [state, ...path] = stateName.split("/").reverse();
            riveRef.current?.fireStateAtPath(state, path.reverse().join("/"));
          } else {
            riveRef.current?.fireState(stateMachineName, stateName);
          }
        };

Any ideas? Thank you ❤️

Logcat

08-30 10:37:22.779 32224  1111 F p.myapp.debu: java_vm_ext.cc:578] JNI DETECTED ERROR IN APPLICATION: JNI CallVoidMethodV called with pending exception app.rive.runtime.kotlin.core.errors.StateMachineException: No StateMachine found with name .
08-30 10:37:22.779 32224  1111 F p.myapp.debu: java_vm_ext.cc:578]   at app.rive.runtime.kotlin.core.StateMachineInstance app.rive.runtime.kotlin.core.Artboard.stateMachine(java.lang.String) (Artboard.kt:137)
08-30 10:37:22.779 32224  1111 F p.myapp.debu: java_vm_ext.cc:578]   at java.util.List app.rive.runtime.kotlin.controllers.RiveFileController.getOrCreateStateMachines(java.lang.String) (RiveFileController.kt:607)
08-30 10:37:22.779 32224  1111 F p.myapp.debu: java_vm_ext.cc:578]   at void app.rive.runtime.kotlin.controllers.RiveFileController.processAllInputs() (RiveFileController.kt:523)
08-30 10:37:22.779 32224  1111 F p.myapp.debu: java_vm_ext.cc:578]   at void app.rive.runtime.kotlin.controllers.RiveFileController.advance(float) (RiveFileController.kt:264)
08-30 10:37:22.779 32224  1111 F p.myapp.debu: java_vm_ext.cc:578]   at void app.rive.runtime.kotlin.renderers.RiveArtboardRenderer.advance(float) (RiveArtboardRenderer.kt:51)
08-30 10:37:22.779 32224  1111 F p.myapp.debu: java_vm_ext.cc:578]
08-30 10:37:22.779 32224  1111 F p.myapp.debu: java_vm_ext.cc:578]     in call to CallVoidMethodV
08-30 10:37:22.780   779   855 D EnterpriseController: netId is 0
08-30 10:37:22.780   779   855 E Netd    : getNetworkForDns: getNetId from enterpriseCtrl is netid 0
08-30 10:37:22.780   779   855 D DnsProxyListener: DNSDBG::dns addrinfo af 0 - 10252
08-30 10:37:22.813   779  1112 E ResolverController: No valid NAT64 prefix (602, <unspecified>/0)
08-30 10:37:22.974 32224  1111 F p.myapp.debu: thread.cc:2348] No pending exception expected: app.rive.runtime.kotlin.core.errors.StateMachineException: No StateMachine found with name .
08-30 10:37:22.974 32224  1111 F p.myapp.debu: thread.cc:2348]   at app.rive.runtime.kotlin.core.StateMachineInstance app.rive.runtime.kotlin.core.Artboard.stateMachine(java.lang.String) (Artboard.kt:137)
08-30 10:37:22.974 32224  1111 F p.myapp.debu: thread.cc:2348]   at java.util.List app.rive.runtime.kotlin.controllers.RiveFileController.getOrCreateStateMachines(java.lang.String) (RiveFileController.kt:607)
08-30 10:37:22.974 32224  1111 F p.myapp.debu: thread.cc:2348]   at void app.rive.runtime.kotlin.controllers.RiveFileController.processAllInputs() (RiveFileController.kt:523)
08-30 10:37:22.974 32224  1111 F p.myapp.debu: thread.cc:2348]   at void app.rive.runtime.kotlin.controllers.RiveFileController.advance(float) (RiveFileController.kt:264)
08-30 10:37:22.974 32224  1111 F p.myapp.debu: thread.cc:2348]   at void app.rive.runtime.kotlin.renderers.RiveArtboardRenderer.advance(float) (RiveArtboardRenderer.kt:51)
08-30 10:37:22.974 32224  1111 F p.myapp.debu: thread.cc:2348]
08-30 10:37:22.996 32224  1111 F p.myapp.debu: runtime.cc:642] Runtime aborting --- recursively, so no thread-specific detail!

[leemhenson]

I have encountered exactly this issue, also via fireStateAtPath to trigger an animation in an artboard. I believe the bug has been resolved in rive-android 9.9.2 here and documented in the release notes here.

Currently rive-react-native is locked to rive-android 9.5.1 here.

How much of a jump is it from 9.5.1 to 9.9.2? Could you provide any idea how long it's likely to take to pull this bug fix in? Or would it be possible to backport the fix in rive-android to a new 9.5.1-patch or equivalent?

Thanks

[dan-phantom]

@leemhenson probably a patch-package will do it