Executions
A background function call from your application triggers a run on the Defer Platform: an execution.
This page covers the lifecycle of an execution and the associated configurations.
Configuration and defaults
For information regarding maximum durations or other limits, please refer to Limits.
| Default | Possible values | Description | |
|---|---|---|---|
| concurrency | 1 | Hobby: 1 Pro: 1-10 | Specify in the background function should benefit from parallelism |
| retries | 0 | 0-15 | Specify how many times a failed execution should be retried |
| Node version | 16 | 16, 18 | The Node version used is configured at the environment level and used for both Builds and Executions. |
Error handling
Any error outside of a background function execution (steps 1, 2, 4, 5) would update the execution to “Failed”, without retry. In such an event, you will be notified on Slack and will be able to rerun it from the Dashboard.
Out of memory behavior
A background function execution reaching the memory limit will be stop as failed, without retry.
Concurrency
Eventually FIFO
A background function, when configured as FIFO (concurrency: 1), will be process executions one by one.
However, please note that our Scheduler - at the moment - is eventually FIFO, doing best effort to respect the queueing order.
Concurrency account limits
Each account gets a maximum concurrency (Hobby: 1, Pro: 10) that take precedence on the configured background functions concurrency.
For example, on a Pro Plan, if 2 background functions with concurrency: 10 triggers 100 executions each, the Defer Platform will takes 5 of each concurrently, matching the account maximum concurrency (10).
Retries
When configured, Defer applies an exponential backoff (opens in a new tab) (with random jitter) retry algorithm to a failed execution:
| Execution time | 1st retry time | 2nd retry time | 3rd retry time | |
|---|---|---|---|---|
importContacts() | t1 | t2 = t1 + (16 - 36s) | t3 = t2 + (31 - 61s) | t4 = t3 + (96 - 136s) |
This approach ensures that retries are distributed and works well for rate-limited executions.
Execution result
The value returned by a background function should be a non-null value (void is permitted).
Please note that the execution result (return value) has a maximum size limit and must be serializable.
Date and time
Background functions are executed with a UTC timezone configuration.
Please take it in consideration when writing date/time-related logic in your background functions.
Reserved Environment variables
The following Environment variables are reserved and will be overrided if configured on the environment's settings.
DEFER_TOKENNODE_ENVFORCE_COLORNODE_DEBUGNODE_DEBUG_NATIVENODE_DISABLE_COLORSNODE_EXTRA_CA_CERTSNODE_ICU_DATANODE_NO_WARNINGSNODE_OPTIONSNODE_PATHNODE_PENDING_DEPRECATIONNODE_PENDING_PIPE_INSTANCESNODE_PRESERVE_SYMLINKSNODE_REDIRECT_WARNINGSNODE_REPL_HISTORYNODE_REPL_EXTERNAL_MODULENODE_SKIP_PLATFORM_CHECKNODE_TLS_REJECT_UNAUTHORIZEDNODE_V8_COVERAGENO_COLOROPENSSL_CONFSSL_CERT_DIRSSL_CERT_FILEUV_THREADPOOL_SIZE
NODE_ENV is set with prod value when the function runs.
FAQ
All queued executions are stored on disk storage - not in memory - and replicated across multiple A/Z for better reliability.
Each execution happens in an isolated container with an allocated VPC and storage. It is not possible to communicate between executions, and each background function source is fetched securely.
Each function belongs to a dedicated scheduling queue, preventing abuse from a specific user. Also, our infrastructure auto-scales to ensure a reasonable processing time (see Limits).
A Defer execution runs in a container, enabling long-running jobs (>15min) and no limitations on native dependencies.
Yes; however, an execution storage is ephemeral and gets removed after the execution ends. Also, please refer to Limits for storage limitations.
Expect a cold start ranging from 1 to 3 seconds, depending on the number of dependencies of your project and the size of your bundled background function (with its import).