search

hirosystems / stacks-blockchain-api

API for the Stacks blockchain
https://stacks-blockchain-api.vercel.app
GNU General Public License v3.0
170 stars 108 forks source link

Respond with `503 - Service Unavailable` while stacks-node is syncing #698

Open zone117x opened 2 years ago

zone117x commented 2 years ago

When the API and stacks-node are both started, the API immediately boots the event observer http server in order to prevent an inter-process deadlock. However, the API waits until the stacks-node's http server is responsive to /v2/info before initializing it's own public http server. It does this because many endpoints will not function correctly until the stacks-node RPC server is responsive. The code responsible for this behavior is: https://github.com/blockstack/stacks-blockchain-api/blob/538d3b1fbd9f06edd407552a6c61671de1b45923/src/index.ts#L115-L121

While the stacks-node is initializing, it can be unresponsive for quite some time (hours in some cases), and the API can appear to be in a confusing state.

The API should init its public http server and respond with 503 - Service Unavailable status during this period. The body should include the API's currently known block height in the response payload. Once https://github.com/blockstack/stacks-blockchain/pull/2768 is ready, the API can use it to return a more useful syncing progress indicator.

wileyj commented 2 years ago

While 503 is technically correct for the status during startup, i'd argue to use a custom 5XX status code here since health checks would see the 503 and assume the service is dead (restarting the service in some cases).

We had a similar discussion for stacks-blockchain: https://github.com/blockstack/stacks-blockchain/pull/2768#issuecomment-882587477

If the proposed 503 is used, it would become more difficult to know if there was an actual 503 or if the service was simply init'ing without manually checking the logs of the service.

MHassanTariq commented 2 years ago

I'm working on this issue

zone117x commented 2 years ago

@MHassanTariq might be best to hold off until https://github.com/blockstack/stacks-blockchain/pull/2768 is completed or further along, since we'll likely copy their status code and the sync progress if possible.

agraebe commented 2 years ago

removing priority because this is on hold until 2768 is further along

sabbyanandan commented 11 months ago

Hi, @zone117x. Given various improvements in upstream and Stacks Blockchain API, this is an old issue and likely not an issue anymore. When you get a chance, review this once more, and decide whether we can close this, please?

zone117x commented 11 months ago

It would probably still be helpful if the API responded with something to indicated sync status. However, any changes for that are still blocked on upstream, e.g. https://github.com/stacks-network/stacks-blockchain/pull/3729 (and potentially another change for that sync/health info to be pushed through the event emitter).