fix: poll

[sylingd]

Explanation of the poll() Function Modification

Problem Identified

The original poll() function had inconsistent waiting behavior:

• If immediate=false, it waited before the first poll but did not wait between subsequent polls, causing them to execute too quickly (as seen in the logs).
• If immediate=true, it skipped the first delay, but still did not enforce delays between retries, leading to rapid polling.

2025-08-13T17:14:33.872Z amo-upload Start polling for the upload result
2025-08-13T17:14:38.872Z amo-upload Polling 0
2025-08-13T17:14:39.394Z amo-upload Polling 1
2025-08-13T17:14:39.930Z amo-upload Polling 2
2025-08-13T17:14:40.868Z amo-upload Polling 3
2025-08-13T17:14:40.877Z amo-upload Polling 4
2025-08-13T17:14:41.356Z amo-upload Polling 5
2025-08-13T17:14:42.036Z amo-upload Polling 6
2025-08-13T17:14:42.468Z amo-upload Polling 7
2025-08-13T17:14:42.925Z amo-upload Polling 8
2025-08-13T17:14:43.343Z amo-upload Polling 9
2025-08-13T17:14:43.760Z amo-upload Polling 10
2025-08-13T17:14:44.252Z amo-upload Polling 11
2025-08-13T17:14:44.728Z amo-upload Polling 12

Desired Behavior

We want the polling to follow a predictable timing pattern:

1. When immediate=true:

   • First attempt (i=0): Execute immediately (no initial delay).
   • Subsequent attempts (i>0): Wait interval before each retry.

2. When immediate=false:

   • First attempt (i=0): Wait interval before starting.
   • Subsequent attempts (i>0): Wait interval before each retry.

Solution Implemented

The modified logic ensures consistent delays:

if (!immediate || i > 0) await delay(interval);

• immediate=true:

  • i=0 → (!false || 0>0) = false → no delay (immediate execution).
  • i>0 → (!false || true) = true → always delay.

• immediate=false:

  • i=0 → (!true || false) = false → delay (waits before first poll).
  • i>0 → (!true || true) = true → always delay.

[gera2ld]

Thank you!