import { MessageQueue, MessageQueueDepth, MessageQueueEnqueueOptions, MessageQueueListenOptions } from "@fedify/fedify";
import { ChannelModel } from "amqplib";

//#region src/mq.d.ts
/**
* Options for ordering key support in {@link AmqpMessageQueue}.
*
* Ordering key support requires the `rabbitmq_consistent_hash_exchange`
* plugin to be enabled on the RabbitMQ server.  You can enable it by running:
*
* ```sh
* rabbitmq-plugins enable rabbitmq_consistent_hash_exchange
* ```
*
* @since 2.0.0
*/
interface AmqpOrderingOptions {
  /**
  * The name of the consistent hash exchange to use for ordering.
  * Defaults to `"fedify_ordering"`.
  * @default `"fedify_ordering"`
  */
  readonly exchange?: string;
  /**
  * The prefix to use for ordering queues.
  * Defaults to `"fedify_ordering_"`.
  * @default `"fedify_ordering_"`
  */
  readonly queuePrefix?: string;
  /**
  * The number of partitions (queues) to use for ordering.
  * More partitions allow better parallelism for different ordering keys.
  * Defaults to `4`.
  * @default `4`
  */
  readonly partitions?: number;
}
/**
* Options for {@link AmqpMessageQueue}.
*/
interface AmqpMessageQueueOptions {
  /**
  * The name of the queue to use.  Defaults to `"fedify_queue"`.
  * @default `"fedify_queue"`
  */
  readonly queue?: string;
  /**
  * The prefix to use for the delayed queue.  Defaults to `"fedify_delayed_"`.
  * Defaults to `"fedify_delayed_"`.
  * @default `"fedify_delayed_"`
  */
  readonly delayedQueuePrefix?: string;
  /**
  * Whether the queue will survive a broker restart.  Defaults to `true`.
  * @default `true`
  */
  readonly durable?: boolean;
  /**
  * Whether to use native retrial mechanism. If set to `true`, the queue will
  * not acknowledge messages that are not processed successfully, allowing
  * them to be retried later. If set to `false`, messages will be acknowledged
  * whether they are processed successfully or not.
  *
  * Both approaches have their own advantages and disadvantages.  With native
  * retrials, much less chance of losing messages, but timing of retrials is
  * less predictable.  With non-native retrials, retrials are handled by Fedify
  * itself, which allows for more control over the timing and behavior of
  * retrials, but may result in lost messages if the process crashes before
  * acknowledging the message.
  * @default `false`
  * @since 0.3.0
  */
  readonly nativeRetrial?: boolean;
  /**
  * Options for ordering key support.  If provided, the message queue will
  * support the `orderingKey` option in {@link MessageQueueEnqueueOptions}.
  * Messages with the same ordering key will be processed in order,
  * while messages with different ordering keys can be processed in parallel.
  *
  * This feature requires the `rabbitmq_consistent_hash_exchange` plugin
  * to be enabled on the RabbitMQ server.  See {@link AmqpOrderingOptions}
  * for more details.
  *
  * If not provided, ordering key support is disabled and any `orderingKey`
  * option passed to `enqueue()` will be ignored.
  *
  * @since 0.4.0
  */
  readonly ordering?: AmqpOrderingOptions;
}
/**
* A message queue that uses AMQP.
*
* @example
* ``` typescript
* import { createFederation } from "@fedify/fedify";
* import { AmqpMessageQueue } from "@fedify/amqp";
* import { connect } from "amqplib";
*
* const federation = createFederation({
*   queue: new AmqpMessageQueue(await connect("amqp://localhost")),
*   // ... other configurations
* });
* ```
*/
declare class AmqpMessageQueue implements MessageQueue {
  #private;
  readonly nativeRetrial: boolean;
  /**
  * Creates a new `AmqpMessageQueue`.
  * @param connection A connection to the AMQP server.
  * @param options Options for the message queue.
  */
  constructor(connection: ChannelModel, options?: AmqpMessageQueueOptions);
  /**
  * Enqueues a message to be processed.
  *
  * When an `orderingKey` is provided without a `delay`, the message is routed
  * through the consistent hash exchange, ensuring messages with the same
  * ordering key are processed by the same consumer in FIFO order.
  *
  * When both `orderingKey` and `delay` are provided, the message is first
  * placed in a delay queue, then routed to the consistent hash exchange
  * after the delay expires.  This ensures ordering is preserved even for
  * delayed messages.
  *
  * @param message The message to enqueue.
  * @param options The options for enqueueing the message.
  */
  enqueue(message: any, options?: MessageQueueEnqueueOptions): Promise<void>;
  /**
  * Enqueues multiple messages to be processed.
  *
  * When an `orderingKey` is provided without a `delay`, the messages are
  * routed through the consistent hash exchange, ensuring messages with the
  * same ordering key are processed by the same consumer in FIFO order.
  *
  * When both `orderingKey` and `delay` are provided, the messages are first
  * placed in a delay queue, then routed to the consistent hash exchange
  * after the delay expires.  This ensures ordering is preserved even for
  * delayed messages.
  *
  * @param messages The messages to enqueue.
  * @param options The options for enqueueing the messages.
  */
  enqueueMany(messages: readonly any[], options?: MessageQueueEnqueueOptions): Promise<void>;
  getDepth(): Promise<MessageQueueDepth>;
  listen(handler: (message: any) => void | Promise<void>, options?: MessageQueueListenOptions): Promise<void>;
}
//#endregion
export { AmqpMessageQueue, AmqpMessageQueueOptions, AmqpOrderingOptions };