Frontend: limit calls to /status to 0.5hz

[Williangalvani]

I was seeing requests to /status at ~3hz.
I don't expect huge improvements of performance or bandwidth, but this will at the very least making look at the network tab of developer tools more... sane.

Summary by Sourcery

Limit frontend backend status checks to avoid excessive /status requests.

Enhancements:

• Throttle backend status polling by skipping status checks if the backend was recently online.
• Track the last time the backend was confirmed online in the frontend store to support rate limiting of status checks.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Introduces a minimum interval between backend status checks by tracking the last time the backend was seen online and short‑circuiting new /status polling requests if they occur within that window, while preserving the existing shared status-request logic.

Sequence diagram for throttled backend status checks in axios_backend_instance

sequenceDiagram
  actor Browser
  participant AxiosBackendInstance
  participant FrontendStore
  participant BackendAPI

  Browser->>AxiosBackendInstance: sendRequest(config)
  AxiosBackendInstance->>FrontendStore: get last_backend_online_time
  AxiosBackendInstance->>AxiosBackendInstance: compute online_recently
  alt online_recently is true
    AxiosBackendInstance-->>Browser: proceed with original request (no /status)
  else online_recently is false
    AxiosBackendInstance->>FrontendStore: check backend_status_request
    alt backend_status_request is null
      AxiosBackendInstance->>BackendAPI: GET /status
      AxiosBackendInstance->>FrontendStore: setBackendStatusRequest(promise)
    else backend_status_request exists
      AxiosBackendInstance->>FrontendStore: reuse backend_status_request
    end
    FrontendStore-->>AxiosBackendInstance: backend_status_result
    alt backend online
      AxiosBackendInstance->>FrontendStore: setBackendOffline(false)
    else backend offline or timeout
      AxiosBackendInstance->>FrontendStore: setBackendOffline(true)
    end
    AxiosBackendInstance-->>Browser: proceed or fail based on backend status
  end

Loading

Updated class diagram for FrontendStore backend status tracking

classDiagram
  class FrontendStore {
    +Promise~AxiosResponse~ backend_status_request
    +Date last_backend_online_time
    +boolean backend_offline
    +string frontend_id
    +string backend_status_url
    +void setBackendOffline(offline boolean)
    +void setBackendStatusRequest(request Promise~AxiosResponse~)
  }

  class AxiosBackendInstance {
    +minimum_backend_status_check_interval number
    +interceptRequest(config any) Promise~any~
  }

  FrontendStore <.. AxiosBackendInstance: uses
  AxiosBackendInstance --> FrontendStore : reads last_backend_online_time
  AxiosBackendInstance --> FrontendStore : updates backend_status_request
  AxiosBackendInstance --> FrontendStore : calls setBackendOffline

Loading

File-Level Changes

Change	Details	Files
Throttle backend /status checks based on a minimum interval since the backend was last confirmed online.	Define a minimum_backend_status_check_interval constant (2 seconds) used to limit status polling frequency. In the axios backend instance request interceptor, compute whether the backend was online recently and, if so, bypass triggering a new status check and proceed with the current request config. Retain the existing logic that reuses or initiates a backend status request only when the backend has not been confirmed online recently.	core/frontend/src/utils/api.ts
Track the last time the backend was observed as online in the frontend store.	Add last_backend_online_time field to the FrontendStore, initialized to the current time. Update last_backend_online_time whenever setBackendOffline is called with offline=false, i.e., when the backend transitions to an online state. Keep existing backend_offline flag behavior intact while coupling it with the new timestamp tracking.	core/frontend/src/store/frontend.ts

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• Consider storing last_backend_online_time as a numeric timestamp (e.g. number from Date.now()) rather than a Date instance to simplify comparisons and avoid repeated new Date().getTime() calls in the interceptor.
• The minimum_backend_status_check_interval constant would be clearer with units in the name (e.g. ..._ms) and possibly a brief comment indicating it enforces a 0.5 Hz status check rate to make the intent obvious to future readers.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider storing `last_backend_online_time` as a numeric timestamp (e.g. `number` from `Date.now()`) rather than a `Date` instance to simplify comparisons and avoid repeated `new Date().getTime()` calls in the interceptor.
- The `minimum_backend_status_check_interval` constant would be clearer with units in the name (e.g. `..._ms`) and possibly a brief comment indicating it enforces a 0.5 Hz status check rate to make the intent obvious to future readers.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[ES-Alexander]

Suggested change

	const minimum_backend_status_check_interval = 2000
	const minimum_backend_status_check_interval = 2000 // ms

Or in the variable name (like Sourcery suggested), if that's preferable 🤷‍♂️