# kcli rebind


Rebind messages from matching queues into different queue(s).

Rebinding works first by selecting the set of scheduled queues based on matching criteria that you specify via the `--domain`, `--routing-domain`, `--campaign`, `--tenant` and/or `--everything` options.

Each matching queue has its messages removed and assessed by the rebinding logic.

If `--trigger-rebind-event` is in use, each message will be passed to the `rebind_message` event, along with the effective *data* value you specify through a combination of `--data` and/or `--set` parameters.  What actually happens to the message is defined solely by the logic in your `rebind_message` event.

Otherwise, each message will merge the key/value pairs that you specified via `--data` and/or `--set` into the metadata of the message.

After this, the message will be re-inserted into the queue subsystem.

If your rebind action caused any of the envelope recipient (in the case of `--trigger-rebind-event`), `queue`, `tenant`, `campaign` or `routing_domain` meta items to be changed, then the message will be placed into a different queue from its original location; in that case, it will be updated so that it is eligible for immediate delivery and an `AdminRebind` log event will be generated to the logs.

If the queue wasn't changed, then the next-due time of the message will remain unchanged, unless you specified `--always-flush`.  In that case, the message will be placed back into its original queue but be eligible for immediate delivery.

If you do not wish to generate `AdminRebind` log entries, then you can use `--suppress-logging`.

Since the number of messages may be very large, and because processing messages may result in a large amount of I/O to load in every matching message's metadata, the total amount of time taken for a rebind request may be too large to feasibly wait for in the context of a simple request/response.

With that in mind, the rebinding action runs asynchronously: aside from any immediate syntax/request formatting issues, this command will immediately return with no further status indication.

Errors will be reported in the diagnostic log.

## Examples

Move messages from the "example.com" queue to the "foo.com" queue:

kcli rebind --domain example.com --set queue=foo.com

Alternatively:

kcli rebind --domain example.com --data '{"queue": "foo.com"}'


**Usage:** `kcli rebind [OPTIONS] --reason <REASON>`

## Options


* `--domain <DOMAIN>` — The domain name to match. If omitted, any domains will match!

* `--routing-domain <ROUTING_DOMAIN>` — The routing_domain name to match. If omitted, any routing domain will match!

* `--campaign <CAMPAIGN>` — The campaign name to match. If omitted, any campaigns will match!

* `--tenant <TENANT>` — The tenant name to match. If omitted, any tenant will match!

* `--reason <REASON>` — The reason to log in the delivery logs (each matching message will rebind with an AdminRebind record)

* `--always-flush` — Always flush, even if we didn't change the scheduled queue

* `--everything` — Match all queues

* `--suppress-logging` — Do not generate AdminRebind delivery logs

* `--trigger-rebind-event` — Trigger a "rebind_message" event which receives both the message and the data, and then decides what to do to the message. Otherwise, the data will be unconditionally applied to the message metadata

* `--data <DATA>` — Specify a JSON object of key/value pairs which should either be set as meta values, or passed to the rebind_message event (if `--trigger-rebind-event` is in use)

* `--set <KEY=VALUE>` — Set additional key/value pairs. Can be used multiple times