10+ second machine status update latency via API

I’m doing a project where I want to show a nice landing page to a user when their app isn’t started yet. I’m running into problems where the app status is updated 10 seconds after the real status seems to have changed - e.g. the app is stopped and inaccessible or started and accessible but the API still shows a different status.

tl;dr: is there a 5-10 second latency on updating the machine status that is accessible via the GraphQL API?

My proxy does the following:

  1. auto-start and auto-stop are turned off for all user apps
  2. I stop inactive machines after 15 minutes of inactivity and record the status change in a cache
  3. on each request, I check cache for app status; if app is stopped, run a background task to start the app and return a simple HTML loading page that shows a loading animation
  4. the background task starts the app and waits for it to have status “started”, then changes the status in the cache
  5. a JS in the HTML loading page calls an internal API checking the cached status every second until it’s updated

What i’m running into is that the app is accessible at appname.fly.dev at least 5-10 seconds before the status returns started. And when stopping apps, the app does a restart (i.e. the page takes a couple seconds to load) 5-10 seconds before the status check returns stopped.

How do I get around this problem? I know machine status webhooks aren’t built yet though they’ve been discussed. Is there a way to ask the machine directly for its status/assert the response fails?

Have you tried using the Machines API instead of GraphQL? Working with the Machines API · Fly Docs

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.