[Bug] app-side fetch() ignores timeout parameter and drops idle connections (Error -2), 100% reproducible in Power Saving Mode

[SantiagoDGarcia]

When using the fetch API on the app-side to communicate with a slow backend (e.g., an LLM API taking 10-15 seconds to respond), the request frequently fails with code: -2 (network error) after exactly 10 seconds, completely ignoring the timeout: 120000 parameter set in the ZML code.

Under normal conditions, this happens sporadically when the companion phone's screen is locked or the Zepp app is running in the background. The OS native HTTP client seems to kill the "idle" connection. However, if the phone is placed in Power Saving Mode, the issue becomes 100% reproducible, instantly killing the connection at the 10-second mark.

To Reproduce
Steps to reproduce the behavior:

• Create a backend endpoint that delays the response by 12-15 seconds.
• Call this endpoint from the app-side using fetch with a high timeout (e.g., timeout: 120000).
• Trigger the request from the watch under normal conditions with the phone screen locked (fails sporadically).
• Turn on "Power Saving Mode" on the companion Android phone and trigger the request again (fails 3 out of 3 times).
• See error -2 triggered by the companion app exactly at 10 seconds, before the server can respond.

Expected behavior
The app-side fetch engine should keep the connection alive and strictly respect the custom timeout parameter, preventing the companion app's native HTTP client from aggressively destroying the connection as an idle background process, regardless of the phone's screen state or battery mode.

Code Snippet

fetch({
  url: "https://my-slow-backend.com/api",
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ prompt: "large prompt" }),
  timeout: 120000 // <--- This is being ignored by the companion app
}).then(response => {
  console.log(response);
}).catch(error => {
  console.log("Failed exactly at 10s: ", error); 
});

Environment:

Zepp App Version: 7.1.0.2
Amazfit Active 2, Zepp OS 5
OS: Android 16

Additional context
Because the timeout parameter is ignored, it is currently impossible to maintain reliable connections with modern GenAI APIs (which often take >10s to stream/return audio or large text). The only workaround is forcing a Short Polling architecture, which adds unnecessary complexity. Proper timeout handling on the companion app side is highly needed.