Antonio-RiveroMartnez opened a new pull request, #42012:
URL: https://github.com/apache/superset/pull/42012

   ### SUMMARY
   When `GLOBAL_ASYNC_QUERIES` is enabled with the `polling` transport, the 
client polls `/api/v1/async_event/` every `GLOBAL_ASYNC_QUERIES_POLLING_DELAY` 
ms (500ms by default) while there are registered job listeners. When a polling 
request fails, the error is logged and the next poll is scheduled at the full 
configured rate, unconditionally and forever.
   
   This becomes a problem when the failure is persistent. The most common case 
is an expired session: a dashboard tab left open keeps polling at 2 
requests/second indefinitely, receiving a 401/403 on every request. The pending 
job listeners never resolve (the completion events can never be read), so 
polling never stops on its own. Since every request still executes the full 
authentication and authorization stack server-side, idle browser tabs can 
generate significant sustained load on the web workers and the metadata 
database.
   
   This PR applies exponential backoff to the polling loop when requests fail 
consecutively:
   
   - Each consecutive failure doubles the polling delay (`delay * 2^failures`), 
capped at 60 seconds.
   - The first successful poll resets the delay back to the configured value.
   - Behavior during normal operation is unchanged — backoff only kicks in on 
failures.
   
   With the default 500ms delay, a permanently failing client converges to ~1 
request/minute instead of ~120/minute, while still recovering automatically 
(e.g. after the user logs back in) since polling never fully stops.
   
   ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
   N/A — no UI changes.
   
   ### TESTING INSTRUCTIONS
   Unit tests added in `superset-frontend/src/middleware/asyncEvent.test.ts` 
covering the backoff growth and the reset-on-success behavior.
   
   Manual verification:
   1. Enable `GLOBAL_ASYNC_QUERIES` with the `polling` transport and open a 
dashboard so async jobs register listeners.
   2. Invalidate the session (e.g. delete the session cookie) while the tab 
stays open.
   3. Observe in the network tab that requests to `/api/v1/async_event/` back 
off exponentially (500ms → 1s → 2s → ... → 60s cap) instead of continuing at 
500ms.
   4. Log back in — after the next successful poll, the polling interval 
returns to the configured delay.
   
   ### ADDITIONAL INFORMATION
   <!--- Check any relevant boxes with "x" -->
   <!--- HINT: Include "Fixes #nnn" if you are fixing an existing issue -->
   - [ ] Has associated issue:
   - [x] Required feature flags: `GLOBAL_ASYNC_QUERIES` (polling transport)
   - [ ] Changes UI
   - [ ] Includes DB Migration (follow approval process in 
[SIP-59](https://github.com/apache/superset/issues/13351))
     - [ ] Migration is atomic, supports rollback & is backwards-compatible
     - [ ] Confirm DB migration upgrade and downgrade tested
     - [ ] Runtime estimates and downtime expectations provided
   - [ ] Introduces new feature or API
   - [ ] Removes existing feature or API
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to