Timeouts on Identity.appendVisitorInfoForURL

[Faltenreich]

We are experiencing timeouts on calling Identity.appendVisitorInfoForURL. Most requests work fine but we would like to reduce those few hundreds issues every day.

We notice a timeout interval of 500ms for Identity.appendVisitorInfoForURL. This sounds very short and may be the cause of our problem. Is there any option to increase this timeout interval?

Expected Behaviour

Actual Behaviour

Reproduce Scenario (including but not limited to)

Steps to Reproduce

Platform and Version

• Adobe BoM 3.5.1
• Android (targetSdk 35)

Sample Code that illustrates the problem

Identity.appendVisitorInfoForURL(url, object : AdobeCallbackWithError<String> {

    override fun call(urlWithAdobeVisitorInfo: String?) = Unit

    override fun fail(adobeError: AdobeError?) {
        // Called with adobeError.errorName: "general.callback.timeout" and error code: 1
    }
)

Logs taken while reproducing problem

com.adobe.marketing.mobile.Identity$1.fail (Identity.java:365)
com.adobe.marketing.mobile.internal.eventhub.EventHub.registerResponseListener$lambda$12$lambda$11 (EventHub.kt:377)
java.util.concurrent.FutureTask.run (FutureTask.java:264)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run (ScheduledThreadPoolExecutor.java:307)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:644)
java.lang.Thread.run (Thread.java:1012)

[praveek]

@Faltenreich Currently, there’s no way to increase the timeout interval. This timeout is set shorter than others, as the API is usually called early in the app lifecycle and needs to respond quickly.

We’ve observed timeouts during the first install when the SDK downloads the remote configuration first before generating the ECID and responding to the call. As a workaround, consider bundling a configuration file with the app as mentioned in this blog post. This ensures the ECID and visitor information are generated even during first launch, reducing the likelihood of a timeout.

If you still encounter timeouts, consider implementing a custom retry mechanism in your app by calling the API multiple times.

[Faltenreich]

@praveek Thank you for your quick response and your suggestions!

This timeout is set shorter than others, as the API is usually called early in the app lifecycle and needs to respond quickly.

I do not understand how a timeout correlates with faster response times. If I understand correctly, the timeout simply sets the timeframe in which the client (we) is waiting for a response from the SDK (you) or rather from your (remote?) backend. If that timeframe is exceeded, the SDK is not waiting anymore and returns an error, which is the case we are running into. In that case, increasing the timeout sounds like a valid option to me. Would you consider that for a future update?

[praveek]

Yes, a shorter timeout doesn’t necessarily mean a faster response. Instead, it ensures that if a request takes too long, the app gets a timeout error, allowing it to trigger a fallback rather than waiting indefinitely for the response. Ideally, having a configurable timeout would be the best solution, but we need to ensure it works consistently across all APIs, which we’re actively tracking. In the meantime, you can try the workarounds I mentioned earlier.