QueueResource is the Activate resource type used to queue, retry, suspend, resume, and throttle work that should not fail immediately when a downstream dependency is unavailable, busy, or rate-limited.

Unlike a simple rate limiter, a QueueResource provides a complete queue-backed workflow replay mechanism. It allows workflows to pause safely, be retried later by the Orchestrator, and resume from the point at which they were suspended.

Typical use cases include:

A QueueResource owns an ActivateBackgroundQueue.

Internally, the queue is created or retrieved using:

The queue is keyed by the resource path, ensuring that each queue resource maintains its own independent workload.

The queue is responsible for:

At a high level:

A QueueResource allows Activate to:

A QueueResource is configured as a resource node within Activate.

A common pattern is:

The parent queue resource typically contains shared defaults while child queue resources represent individual integration queues.

When a queue is first required, GetQueue() requests a queue instance from the background thread manager.

If one does not already exist:

creates a new ActivateBackgroundQueue.

TryGetQueue() performs the same lookup without creating a new queue.

When a queue starts, Activate loads any queued jobs that were previously persisted:

Each loaded job ID is added back into the queue.

This allows queued work to survive:

This process is commonly referred to as queue rehydration.

Queue_Count represents the current queue depth.

When the Orchestrator is running:

When the Orchestrator is not running:

The background queue updates this value automatically.

Queue_Count is operational state, not deployment configuration.

Do not manually configure it.

ShouldTry is the primary gate used before calling external systems.

This behaviour is often misunderstood.

Internally, the logic behaves approximately as follows:

This prevents new work from bypassing jobs that are already waiting in the queue.

A queued retry should always get the next opportunity to run before new work is introduced.

QueueResource does not simply rate-limit requests.

New jobs are blocked while work is already queued, but jobs already inside the queue are allowed to continue retrying.

This ensures:

A typical service desk integration follows this pattern:

Design principles:

This pattern is widely used in service desk integrations.

QueueJob(job) is used when a workflow explicitly needs to move into the retry queue.

The method:

The practical effect is:

When a queued job is processed:

Activate:

If the workflow returns:

the queue logs the retry and processes it again later.

If an exception occurs:

QueueResource includes a limiter used to control outbound throughput.

Connectors typically use:

This prevents requests from exceeding the queue's configured transaction rate.

The limiter is configured primarily through:

If no limit is configured, the current implementation defaults to approximately:

Rate limiting controls long-term throughput.

Burst capacity controls short-term spikes.

Think of it as a bucket:

When requests arrive:

When the burst is exhausted:

For example:

After a quiet period:

might be allowed immediately.

After the burst is consumed:

becomes the sustained processing rate.

This allows:

Burst capacity is not unlimited parallelism.

It simply allows temporary acceleration before returning to the configured rate.

Retry timing is controlled by:

Example:

The sequence is interpreted as:

Rules:

This allows aggressive retrying for short-lived failures while backing off for longer outages.

For API connectors, the recommended pattern is:

This ensures:

Use one queue per external system.

Good:

Avoid:

unless a shared throttle is intentional.

Queue_Count should never be treated as deployment configuration.

It is runtime state maintained by the queue.

Example:

is aggressive.

Useful for:

Less useful for:

For unstable APIs, use longer retry intervals.

Queue logs show:

These logs are often the fastest way to diagnose queue issues.

QueueResource is Activate's queue-backed retry, replay, suspension, and throttling mechanism.

It allows workflows to:

The typical pattern is:

This makes QueueResource the preferred mechanism for service desk integrations, vendor APIs, and any workflow where temporary failure should not immediately become job failure.