Project Queue icon

Project Queue

Project Queue is Tray's native topic-based message queue. Use the Project Queue connector to publish messages to a topic and the Project Queue Trigger to consume them in a separate workflow, decoupling producer and consumer workflows and throttling downstream execution.

Overview

Project Queue is a topic-based publish/subscribe message queue built into Tray. It lets you decouple two workflows: one workflow publishes messages to a named topic, and a separate workflow consumes those messages as they become available.

Common use cases for this connector:

  • Throttle the execution of a downstream workflow to protect downstream services and prevent resource exhaustion.
  • Decouple a producer workflow from a consumer workflow so they can run and scale independently.
  • Batch process messages instead of triggering a workflow run per individual event.

To use Project Queue, you need two workflows:

  1. Producer - Uses the Project Queue connector to publish messages to a topic.
  2. Consumer - Uses the Project Queue Trigger to fire a workflow when messages are available on that topic.

Authentication

No authentication is required for either the Project Queue connector or the Project Queue Trigger. Both operate using Tray-managed internal credentials; no fields need to be configured in the Auth tab.

Producer (Project Queue connector)

Add the Project Queue connector to the workflow that should publish messages.

Topics only appear after they are created on the trigger side

The Topic dropdown only lists topics that already exist. A topic is created by adding a Project Queue Trigger (Consumer) configured with that topic name - see Consume below. If the topic you expect is not in the dropdown, create a Project Queue Trigger for it first, then come back to this connector.

Add Message to Queue

Publishes a single message to a topic.

Input parameters:

  • Topic (required) - Select the target topic from the dropdown.
  • Message (required) - Content of the message to publish. Maximum size is 256KB.
  • Deduplication ID (optional, advanced) - Controls how duplicate messages are detected. Three options are available:
    • Hash (default) - Tray generates the deduplication ID by hashing the message content, so if the exact same message content is published again, the duplicate is discarded.
    • Provided - Supply your own custom deduplication value instead of relying on the message content.
    • None - Tray generates a random, unique deduplication ID for every message, so no message is ever treated as a duplicate. Use this option if you want to allow duplicate message content to be queued.

Output:

  • ApproximatedMessagesInQueue - Approximate number of messages currently in the topic queue.

Add Messages to Queue

Publishes multiple messages to a topic in a single execution.

Input parameters:

  • Topic (required) - Select the target topic from the dropdown.
  • Messages (required) - List of messages to publish. Maximum 100 messages per execution. Each message has the same Message and Deduplication ID fields described above.

Output:

  • ApproximatedMessagesInQueue - Approximate number of messages currently in the topic queue.

Clean Queue

Removes all pending messages from a topic.

Input parameters:

  • Topic (required) - Select the topic to clear from the dropdown.

Consumer (Project Queue Trigger)

Add the Project Queue Trigger to the workflow that should process messages as they arrive on a topic.

Consume

Fires the workflow when one or more messages are available on the selected topic. Messages are delivered in batches; the workflow does not run when the topic has no messages.

Input parameters:

  • Topic (required) - Name of the topic to consume from. Must be at least 3 characters.
  • Batch Size (required, default 10) - Maximum number of messages retrieved per execution. Maximum value is 10.
  • Max Parallel Executions (optional, default 1) - Maximum number of parallel executions for the topic. Maximum value is 10.

Output:

  • messages - Array of message strings delivered in this batch.
  • ApproximatedMessagesInQueue - Approximate number of messages remaining in the topic queue.
No messages available

If no messages are available on the topic when the trigger checks, the workflow run is skipped rather than executed with an empty batch.

Batch and concurrency limits

Batch Size and Max Parallel Executions both accept values between 1 and 10. Values outside this range are rejected with a validation error.

Deduplication is based on the Deduplication ID, not the message content

Uniqueness in the queue is determined by the Deduplication ID, not directly by the contents of the message. With the default Hash option, that ID happens to be derived from the message content, so publishing identical message content twice produces the same Deduplication ID and the second message is discarded. Two messages with the same Deduplication ID are always treated as duplicates, even if their message content is different - the second one is discarded.

If you want every publish to be accepted, even when the message content repeats (for example, retries or repeated events that should each be processed), choose the None option for Deduplication ID - Tray generates a random, unique value for each message so nothing is ever discarded as a duplicate. Alternatively, choose Provided to control the deduplication value yourself.

Additionally, once a message is consumed, its Deduplication ID cannot be reused for 5 minutes - a message published with that same Deduplication ID during this window is discarded, even though the original message has already left the queue.

Use Cases

  1. Throttled downstream processing - Publish events from a high-throughput workflow to a topic, and consume them from a separate workflow with a bounded Batch Size and Max Parallel Executions to protect downstream services and prevent resource exhaustion from an API rate limit.
  2. Producer/consumer decoupling - Let a producer workflow finish quickly by publishing to a queue, while a consumer workflow processes messages independently and can be scaled or modified without changing the producer.
  3. Deduplicated event ingestion - Rely on the default content-hash deduplication (or a custom deduplication ID) to avoid processing the same event twice when a producer may retry or send duplicates.

Available Operations

Please see the Full Operations Reference at the end of this page for complete details on all available operations.

Was this page helpful?