Task runs
Last updated
Last updated
When an event is processed by a task, it is called a task run.
Each Shypyard app is allocated with a fixed number of workers, depending on the plan. Every new event is pushed on a queue for the app, and is then processed by the workers.
Higher number of works will mean higher processing throughput, but because the queue can hold up to 20k events, even if you have peak traffic, the events will gradually be processed by the workers.
Generally events are processed in the same order as they are received.
We will retry the task run up to 3 total times upon failure (exception in Javascript). Each time the task fails for the event, the event will be re-processed after up to 90 seconds of delay.
Note that each retries will have the same task run ID, but different request ID. For example, you can see in this screenshot, there is a single run ID, and there are 2 total task executions, each with a different request ID.
A task can trigger other tasks (or itself). When that happens, the triggered task runs are referred to as child runs. The original run is referred to as the root run.
Child runs are grouped under the same root run, and can be visualized in the log view very clearly.
You may notice that some events seem to take a second or two longer than subsequent events. The reason here is that Shypyard takes down the execution environment for your task if the app is not processing events for roughly 5 to 10 minutes. When you receive another event, then we would create a new execution environment for processing the event. Initializing this environment usually take about a second or two, which is why you see the small delay. This is known as "cold start" and is a common phenomenon for serverless platforms.
