Description
Describe the bug
Although PrebidMobile.setTimeoutMillis()
effect for readTimeout was previously fixed in version 1.14 (The previous issue ticket) to correctly apply a custom timeout for network requests, in versions 2.2.3 and 3.0.0 this setting no longer takes effect. The read timeout is hardcoded to SOCKET_TIMEOUT
in BaseNetworkTask.java
, rather than using the value from setTimeoutMillis()
.
To Reproduce
Steps to reproduce the behavior:
- Set a custom timeout using
PrebidMobile.setTimeoutMillis(10000);
- Trigger a demand fetch from the SDK
- Simulate a slow or delayed response (e.g., with a proxy or mock server)
- Observe that the timeout still follows the default
SOCKET_TIMEOUT
instead of the custom value
Expected behavior
The network request timeout (especially readTimeout
) should follow the value set by PrebidMobile.setTimeoutMillis()
. This was the behavior fixed in version 1.14.
Screenshots
N/A – this is based on code behavior.
Desktop (please complete the following information):
- OS: macOS Sonoma
- Browser: N/A
- Version: N/A
Smartphone (please complete the following information):
- Device: Google Pixel 6
- OS: Android 13
- Browser: N/A
- Version: N/A
Additional context
Code reference from BaseNetworkTask.java
in 3.0.0:
connection.setReadTimeout(SOCKET_TIMEOUT);
This seems to be a regression.
Can you confirm if this was intentional or should be considered a bug?