Queue
For requests that take longer than several seconds, as it is usually the case with AI applications, we have built a queue system.
Utilizing our queue system offers you a more granulated control to handle unexpected surges in traffic. It further provides you with the capability to cancel requests if needed and grants you the observability to monitor your current position within the queue. Besides that using the queue system spares you from the headache of keeping around long running https requests.
Queue endpoints
You can interact with all queue features through a set of endpoints added to you function URL via the queue
subdomain. The endpoints are as follows:
Endpoint | Method | Description |
---|---|---|
queue.fal.run/{appId} | POST | Adds a request to the queue |
queue.fal.run/{appId}/requests/{request_id}/status | GET | Gets the status of a request |
queue.fal.run/{appId}/requests/{request_id}/status/stream | GET | Streams the status of a request until it’s completed |
queue.fal.run/{appId}/requests/{request_id} | GET | Gets the response of a request |
queue.fal.run/{appId}/requests/{request_id}/cancel | PUT | Cancels a request |
For instance, should you want to use the curl command to submit a request to the aforementioned endpoint and add it to the queue, your command would appear as follows:
Here’s an example of a response with the request_id
:
The payload helps you to keep track of your request with the request_id
, and provides you with the necessary information to get the status of your request, cancel it or get the response once it’s ready, so you don’t have to build these endpoints yourself.
Request status
Once you have the request id you may use this request id to get the status of the request. This endpoint will give you information about your request’s status, it’s position in the queue or the response itself if the response is ready.
Here’s an example of a response with the IN_QUEUE
status:
Status types
Queue status
can have one of the following types and their respective properties:
-
IN_QUEUE
:queue_position
: The current position of the task in the queue.response_url
: The URL where the response will be available once the task is processed.
-
IN_PROGRESS
:logs
: An array of logs related to the request. Note that it needs to be enabled, as explained in the previous section.response_url
: The URL where the response will be available.
-
COMPLETED
:logs
: An array of logs related to the request. Note that it needs to be enabled, as explained in the previous section.response_url
: The URL where the response is available.
Logs
Logs are disabled by default. In order to enable logs for your request, you need to send the logs=1
query parameter when getting the status of your request. For example:
When enabled, the logs
attribute in the queue status contains an array of log entries, each represented by the RequestLog
type. A RequestLog
object has the following attributes:
message
: a string containing the log message.level
: the severity of the log, it can be one of the following:STDERR
|STDOUT
|ERROR
|INFO
|WARN
|DEBUG
source
: indicates the source of the log.timestamp
: a string representing the time when the log was generated.
These logs offer valuable insights into the status and progress of your queued tasks, facilitating effective monitoring and debugging.
Streaming status
If you want to keep track of the status of your request in real-time, you can use the streaming endpoint.
The response is text/event-stream
and each event is a JSON object with the status of the request exactly as the non-stream endpoint.
This endpoint will keep the connection open until the status of the request changes to COMPLETED
.
It supports the same logs
query parameter as the status.
Here is an example of a stream of status updates:
Cancelling a request
If your request is still in the queue and not already being processed you may still cancel it.
Getting the response
Once you get the COMPLETED
status, the response
will be available along with its logs
.
Here’s an example of a response with the COMPLETED
status: