Help Center

Menu

Rebound

The rebound feature helps you handle temporary downstream failures without losing data. When a component cannot process a message, the platform returns that message to a rebound queue and retries it later.

An example of this is in the syncing of product details and prices between ERP and Shop. These systems have different hierarchical structures for products and prices so the data cannot be sent through the same process. Because of this, prices and product data are synced separately using parallel processes. However, a product must exist before a price can be added to it. If the pricing data arrives before the product data, it cannot be stored. Instead of failing immediately, the rebound feature sends the price message back to the sender component. The message is placed in a separate queue and retried later.

How the rebound works

When a component does not have enough information to process a message, it emits a rebound event. The platform sends that message to the rebound queue for a delay period. After the delay period ends, the message returns to the processing queue.

A message can rebound 10 times. The first rebound waits for one minute. The delay increases after each additional rebound. After the tenth rebound, the message is rejected and the flow run reports an error.

Diagram showing rebound message retry flow.

Where rebound applies

Rebound behavior depends on where it is triggered.

Platform rebound sends the message to the rebound queue described in How the rebound works and retries it on a delay schedule. Some components also run their own retry logic and may show counters such as reboundCount in logs (for example on the Database/JDBC component). That counter does not mean rebound was emitted from a Code or error-handling step elsewhere in the flow.

Platform rebound is implemented only for a limited set of components and actions. There is no canonical list to link for components and actions with built-in rebound. Check each component and action reference to confirm whether platform rebound is available. Most components use their own dedicated retry logic when retries are needed. The JDBC component supports rebound for some actions, but the Select Query action does not use the platform rebound mechanism.

If you call emit('rebound', …) in a Code step or in a script attached to an Error Handling step, that rebound applies only when the error occurs during execution of that step’s script. It does not retry failures in other flow steps, and it does not enable rebound for a JDBC or other downstream step.

Rebound code in a Code or error-handling step does not retry a failing Database/JDBC Select Query step. For that scenario, use a component and action that supports platform rebound, or the component’s own retry behavior where documented.

JDBC Select Query failures show the actual error message on the execution error page. For example:

java.sql.SQLException: Access denied for user 'test'@'static.11.222.333.444.clients.your-server.com' (using password: YES)
java.sql.SQLSyntaxErrorException: Access denied for user 'test'@'%' to database 'test_db'

Emitting a rebound in Node.js

Use emit('rebound', reason) when your component detects a temporary condition and must retry later. Pass an Error object or a string as the reason.

exports.process = processTrigger;

function processTrigger(msg, cfg) {
  const self = this;
  self.logger.info('Rebounding message because dependency is unavailable');
  self.emit('rebound', new Error('Dependency is not ready'));
  self.emit('end');
}

This page uses the exports.process / processTrigger pattern. You can also use the run(msg, cfg, snapshot) pattern instead; both are correct.

Use this pattern when the Code step itself detects a temporary condition during its own execution and must retry that step’s processing. It does not retry errors raised by other steps in the flow.

Verifying rebound behavior

To verify rebound behavior in logs:

  1. The platform does not log a default message that confirms platform rebound was invoked (separate from component-internal counters such as reboundCount).

  2. Add a log line immediately before emit('rebound', …​).

  3. Include a clear reason in the rebound message so you can correlate retries.

  4. Confirm whether the run eventually succeeds or reaches the retry limit.

If the platform exhausts all rebound attempts, it rejects the message and reports an error for that run.