You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we support GET /documents/{id} to get the status of a document. It would be nice if we could have something like GET /documents/{id}?wait_for_terminal=True or something, which would cause the wait to happen in the server rather than looping in the client.
Specifically, we can use postgres notifications to wake up threads on the server that are waiting for specific document ingestion updates, so this would let us avoid polling entirely.
The text was updated successfully, but these errors were encountered:
This may not be ideal. While it might be useful, it would require the client set a high timeout for this method call. Many libraries don't make it easy to set per-call timeouts, so you'd need to mutate the client or set it high for all calls, which in turn wouldn't detect legitimate errors quickly. Perhaps the best option here is to actually have the client periodically call GET /documents/{id} and see if it is done. That should call should be quick.
Closing -- the goal of making it easier to wait for a specific status is accomplished with the more specific endpoint, while as noted having a "long" REST method seems not desirable at this time
Currently, we support
GET /documents/{id}
to get the status of a document. It would be nice if we could have something likeGET /documents/{id}?wait_for_terminal=True
or something, which would cause the wait to happen in the server rather than looping in the client.Specifically, we can use postgres notifications to wake up threads on the server that are waiting for specific document ingestion updates, so this would let us avoid polling entirely.
The text was updated successfully, but these errors were encountered: