Invoking JS function from native code twice

[skjolber]

What happened?

Hi,

we are writing a plugin for handling travel rights in public transport. As part of this work, we manage one or more key-pairs which are used to authenticate against the backend. The key-pair has a rather complex lifecycle. Master state is determined by the server.

As part of this work we are providing apps with a plugin method which allows them to easily interact with the backend:

const result = await clientRef.current?.remoteClientCallHandler<string>({
	tokenContextId: DEFAULT_TOKEN_CONTEXT_ID,
	tokenEncodingRequest,
	fn: async (params) => {
	    // custom work there
	}
})

where fn is

export type TravellerClientCall<R> = (input: RemoteClientCallInput) => Promise<R>

and params is some values we need the client to forward in order to be authenticated, i.e.

export type RemoteClientCallInput = {
    tokenId: string
    secureContainerToken: string
    attestation: Attestation | undefined
    correlationId: string
}

So the async JS-function fn is essentially passed to native code, then invoked from an executor thread in Android.

In native (Java) code, invoking fn returns a Promise<Promise<MetadataResult>> where MetadataResult accounts for various expected throwable errors. This works as expected, i.e. first waiting for Promise<MetadataResult> and then MetadataResult.

The problem arises when we want to invoke fn twice from a single TravellerClientCall when the first fn-invocation throws an error, the second fn-invocation hangs forever. To be more precise, awaiting MetadataResult hangs on the second invocation of fn.

However the fn JS code actually executes a second time (returns a value, does not throw). And the hang is not happening if we insert an await sleep(1 millisecond) in the code path which runs on the second invocation. So this indicates some kind of race condition / signalling / threading problem. To be clear, in the unit test, the fn returns almost immidiately. Everything is async.

So what we are wondering is whether this approach is expected to work and/or any obious solution we might have missed, and how to continue from here - I have already tried everything I can think of.

Reproduceable Code

-

Relevant log output

A thread dump indicates 


2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W  "default-idleing-pool-thread-1" state=WAITING
2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W      at jdk.internal.misc.Unsafe.park(Native Method)
2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W      at java.util.concurrent.locks.LockSupport.park(LockSupport.java:226)
2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W      at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1840)
2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W      at java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:3797)
2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W      at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3738)
2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W      at java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1874)
2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W      at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2048)
2026-07-15 18:20:43.183 24905-24925 HARNESS_THREADDUMP      com.abtmobileclientsdkexample        W      at com.margelo.nitro.abt.JavaHybridAbtMobileClientSDK.lambda$remoteClientCallHandlerImpl$7(JavaHybridAbtMobileClientSDK.java:640)

Device

Android 17 Emulator

Nitro Modules Version

0.36.1

Nitrogen Version

0.36.1

Can you reproduce this issue in the Nitro Example app here?

I didn't try (⚠️ your issue might get ignored & closed if you don't try this)

Additional information

• I am using Expo
• I am using nitrogen
• I have read and followed the Troubleshooting Guide.
• I created a reproduction PR to reproduce this issue here in the nitro repo. (See Contributing for more information)
• I searched for similar issues in this repository and found none.

[mrousavy]

Hello! Thanks for the report, can you please add this to the example app here so the bug can be reproduced in CI? Based on your description it should be simple to add in a single method.

[skjolber]

@mrousavy see #1440

[skjolber]

For future reference, this was solved by not using Java<->Kotlin CustomContinuation found on the internet, but rather the below PromiseHelper , i.e.

CompletableFuture<Promise<Wrapper>> result1 = new CompletableFuture<>();
PromiseHelper.wire(call, result1);
Wrapper wrapper = result1.get(futureGetTimeoutMs, TimeUnit.MILLISECONDS);

with

import com.margelo.nitro.core.Promise
import java.util.concurrent.CompletableFuture

/**
 * Java-friendly bridge for [Promise.then] / [Promise.catch].
 *
 * ## Why this exists
 *
 * The previous pattern used in [com.margelo.nitro.abt.JavaHybridAbtMobileClientSDK]:
 * ```java
 * promise.await(new CustomContinuation<>(future));
 * future.get();
 * ```
 * is broken when `promise` is **already resolved** by the time `await()` is called.
 * Kotlin's `SafeContinuation` (used inside `suspendCoroutine`) returns the value
 * directly from `await()` without ever calling `CustomContinuation.resumeWith()`,
 * leaving `future` permanently incomplete ? so `future.get()` blocks forever.
 * See https://github.com/mrousavy/nitro/issues/1439.
 *
 * ## Fix
 *
 * Use [Promise.then] / [Promise.catch] instead.  These always complete `future`
 * regardless of whether the Promise is already settled or resolves later.
 * `catch` is a reserved keyword in Java and cannot be called from Java source,
 * so this object provides a single static helper [awaitBlocking] that is fully
 * accessible from Java.
 */
object PromiseHelper {

    /**
     * Wires [promise] to [future] via [Promise.then] and [Promise.catch] so that
     * [future] is always completed ? even when [promise] is already settled.
     *
     * Intended as a drop-in replacement for:
     * ```java
     * promise.await(new CustomContinuation<>(future));
     * ```
     *
     * Usage from Java:
     * ```java
     * CompletableFuture<T> future = new CompletableFuture<>();
     * PromiseHelper.wire(promise, future);
     * T result = future.get();
     * ```
     *
     * @param promise the Nitro [Promise] to observe
     * @param future  the [CompletableFuture] to complete once [promise] settles
     */
    @JvmStatic
    fun <T> wire(promise: Promise<T>, future: CompletableFuture<T>) {
        promise.then { future.complete(it) }
        promise.catch { future.completeExceptionally(it) }
    }
}