This file is automatically generated by the update_all.ps1 script using the Chocolatey-AU module.
Ignored | History | Force Test | Releases
This file is automatically generated by the update_all.ps1 script using the Chocolatey-AU module.
Ignored | History | Force Test | Releases
PR: rabbitmq/amqp091-go#339 Author: suchitd (Suchit Dhakate) Reviewed: 2026-06-04 Reviewer: AI (Claude) with @lukebakken guidance Size: +1824 / -63 lines across 11 files
This review was produced by an AI assistant (Claude Code, Anthropic) under the direction of @lukebakken. Findings were verified against the actual
Audit of the official RabbitMQ AMQP 1.0 Python client. Performed 2026-06-01 against the local checkout.
Repository: https://github.com/rabbitmq/rabbitmq-amqp-python-client
python-qpid-proton (C extension for AMQP 1.0)run_in_executor)This file lets an AI agent resume the PR #148 review session on a different machine without losing context. Read this file, then read rabbitmq-stream-s3-gh-148.md for the actual review output.
amazon-mq/rabbitmq-stream-s3 (private)GitHub issue: rabbitmq/rabbitmq-server#16347
The issue is a review of what remains to be done for per-protocol connection limits. The stream plugin already has stream.max_connections and the web_mqtt plugin already has web_mqtt.max_connections. This document covers the implementation of mqtt.max_connections (PR #16367, under revision) and stomp.max_connections (PR #16368, open).
Status of PR #16367: The initial implementation used ranch:info(RanchRef) (same as the stream plugin). Reviewer @ansd identified that this gives a per-listener count, not a node-wide count. MQTT supports port-to-vhost mapping (multiple listeners on different ports), dual-stack (separate IPv4/IPv6 listeners), and mixed TCP/TLS deployments — each of which is a separate Ranch ref with its own supervisor. With four listeners and max_connections = 1000, the actual node limit would be 4000. The fix is to use the MQTT P
Scope: PR head 3878a85 (24 commits, +1377 / -259). Focus: correctness and design.
The layering is defensible and follows the RabbitMQ precedent for Mnesia-to-Khepri backends (recent-history, JMS, consistent-hash exchanges). Single-bucket timestamp-prefixed keys are a reasonable choice. But the Leveled backend has two critical correctness bugs: storage is never actually freed after delivery, and messages_delayed/1 is wrong for any exchange that has ever delivered a message. There are also several design and robustness issues around the gen_server / migration handoff and a macOS-hostile Makefile. The migration path has a documented "at-most-one extra delivery" tradeoff that is defensible but not exercised by the tests. The PR should not merge as-is; the two critical bugs are blockers. A follow-up topic branch has already landed fixes for several other items in this review; see the section below.
Photos:
https://photos.app.goo.gl/HsBccMnvRbCVmdN58
Resources I've read:
UTC: 2026-09-09 09:55
chocolatey-beam/au-packages
This file is automatically generated by the update_all.ps1 script using the Chocolatey-AU module.
Ignored | History | Force Test | Releases
UTC: 2026-09-09 05:38
rabbitmq/chocolatey-package
This file is automatically generated by the update_all.ps1 script using the Chocolatey-AU module.