How to lazy load hasura, not checking remote schema's for availability #8701
-
Using hasura, with multiple external remote schema's, in a production situation where for example hasura is starting, a check is happening for external remote schema's. However, maybe due to pods/containers starting in a unpredictable order of when an external schema is not available for a brief moment, this should not result in a metadata inconsistent state. As a result, the loaded schema of the remote services is removed from the schema and not available until the remote schema is reloaded. this is not very reliable way to serve a production instance of hasura. In the real world, services can be not available for some time. Is it possible to go lazy on this and assume the remote schema's are still there, but only temporary not available? And load everything from the metadatabase instead? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Lazy loading hasura, without having to check for remote schema availability on startup, is not currently possible. We do have plans to implement a solution for this in the future, but there is no public ETA avaialble. We would suggest waiting for dependencies to be available before starting hasura. Alternatively, you could use the healthz endpoint to check for inconsistencies, then reload metadata once your services are back online. This could allow you to automate this recovery. |
Beta Was this translation helpful? Give feedback.
Lazy loading hasura, without having to check for remote schema availability on startup, is not currently possible.
We do have plans to implement a solution for this in the future, but there is no public ETA avaialble.
We would suggest waiting for dependencies to be available before starting hasura.
Alternatively, you could use the healthz endpoint to check for inconsistencies, then reload metadata once your services are back online. This could allow you to automate this recovery.