If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/rabbitmq/rabbitmq-tutorials shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 2d ago
• 6 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Concentrated ownership — top contributor handles 51% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live rabbitmq/rabbitmq-tutorials repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/rabbitmq/rabbitmq-tutorials.

What it runs against: a local clone of rabbitmq/rabbitmq-tutorials — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in rabbitmq/rabbitmq-tutorials | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of rabbitmq/rabbitmq-tutorials. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/rabbitmq/rabbitmq-tutorials.git
#   cd rabbitmq-tutorials
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of rabbitmq/rabbitmq-tutorials and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "rabbitmq/rabbitmq-tutorials(\\.git)?\\b" \\
  && ok "origin remote is rabbitmq/rabbitmq-tutorials" \\
  || miss "origin remote is not rabbitmq/rabbitmq-tutorials (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "go-amqp/go.mod" \\
  && ok "go-amqp/go.mod" \\
  || miss "missing critical file: go-amqp/go.mod"
test -f "clojure/project.clj" \\
  && ok "clojure/project.clj" \\
  || miss "missing critical file: clojure/project.clj"
test -f "dotnet-amqp/README.md" \\
  && ok "dotnet-amqp/README.md" \\
  || miss "missing critical file: dotnet-amqp/README.md"
test -f "AGENTS.md" \\
  && ok "AGENTS.md" \\
  || miss "missing critical file: AGENTS.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/rabbitmq/rabbitmq-tutorials"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A polyglot tutorial repository containing production-ready RabbitMQ client code samples in 24+ languages (Java, C#, Go, Python, Rust, Kotlin, PHP, C++, etc.). It teaches message queuing patterns—basic send/receive, work queues, pub/sub (fanout, direct, topic routing), and RPC—by providing runnable example programs that connect to a local RabbitMQ broker following the official RabbitMQ tutorials. Monorepo with language-per-directory structure: /java, /python, /go, /rust-amqprs, /clojure, /cpp, etc. Each directory contains parallel tutorial programs (send, receive, worker, emit_log, emit_log_direct, emit_log_topic, rpc_client, rpc_server) with language-specific build/package config (Makefile, go.mod, project.clj, CMakeLists.txt, pom.xml). A single /README.md links all ports; language-specific READMEs exist in each directory (e.g., /java/README.md).

Backend developers and DevOps engineers learning RabbitMQ messaging patterns across their language of choice (Java/Kotlin teams, Go microservices developers, Python async learners, C# .NET teams, etc.). They use this to bootstrap real projects with battle-tested connection and messaging code rather than reading documentation alone.

Actively maintained production reference material. The repo has 24+ language implementations with consistent naming (send.clj, send.go, send.rs, send.java all do the same thing), indicating maturity and community curation. Devcontainer setup and dependency management (go.mod, project.clj, etc.) suggest modern practices, though exact stars/commit-frequency cannot be confirmed from file structure alone.

Low risk for learning; moderate risk if treating as production library. Each language port depends on language-specific AMQP clients (amqplib for JS, pika for Python, amqprs for Rust, etc.) maintained separately, so vulnerabilities in those libraries directly affect all examples. No unified test suite visible across languages, meaning example correctness depends on human code review per port. Single maintainer risk typical of tutorial repos; breaking changes in RabbitMQ protocol or client libraries could orphan older language ports.

Actively expanding language support and keeping examples in sync. The .devcontainer setup (Dockerfile, devcontainer.json) suggests recent focus on developer ergonomics. Dependabot configuration (.github/dependabot.yml) indicates automated dependency maintenance. Newer languages like Zig (20,235 bytes), Kotlin (38,825 bytes), and Rust dual-implementation (amqprs + lapin) show ongoing investment in modern ecosystem languages.

Clone the repo, pick your language, and run examples directly against a local RabbitMQ instance. For Go: git clone https://github.com/rabbitmq/rabbitmq-tutorials.git && cd go && go run send.go. For Python: cd python && pip install pika && python send.py. For Java: cd java && javac -cp .:amqp-client-5.x.x.jar Send.java && java -cp .:amqp-client-5.x.x.jar Send. Requires RabbitMQ running on localhost (via Docker: docker run -d --name rabbitmq -p 5672:5672 rabbitmq:latest).

Daily commands: Language-dependent; examples below:

• Python: cd python && python send.py && python receive.py
• Go: cd go && go run send.go
• Java: cd java && javac -cp .:./lib/* Send.java && java -cp .:./lib/* Send
• Node.js: cd javascript-nodejs && npm install && node send.js
• Rust: cd rust-amqprs && cargo run --example send
• C++: cd cpp && mkdir build && cd build && cmake .. && make && ./send All require RabbitMQ listening on localhost:5672 (default).

• README.md — Entry point documenting all tutorial patterns, prerequisites, and links to official RabbitMQ documentation that every contributor must reference
• go-amqp/go.mod — Go module definition showing core dependencies (Azure/go-amqp, rabbitmq-amqp-go-client) that drive the Go tutorial implementation
• clojure/project.clj — Clojure project configuration defining dependencies and build settings for all Clojure tutorial examples
• dotnet-amqp/README.md — Documents .NET-specific setup and tutorial structure that contributors using C# need to understand
• AGENTS.md — Explains the agent/contributor guidelines and expectations for this multi-language tutorial repository
• .devcontainer/devcontainer.json — Development environment configuration enabling reproducible setup across all contributor machines

• Producer/Sender (AMQP client library (go-amqp, amqp for Clojure, librabbitmq for C++, RabbitMQ.Client for .NET)) — Establishes AMQP connection, declares exchange, publishes messages with routing key
  • Failure mode: Connection refused (broker not running) → application crash; message not persisted if publisher confirms disabled
• Consumer — undefined

Add a new tutorial pattern implementation in existing language

1. Choose target language directory (e.g., go/, clojure/, dotnet-amqp/) (go)
2. Create new file following naming convention: send.go, receive.go, worker.go, rpc_client.go, emit_log_*.go, etc. (go/send.go)
3. Import appropriate AMQP library for the language (e.g., github.com/rabbitmq/amqp091-go for Go) (go/send.go)
4. Implement pattern following existing tutorial structure: connection → channel → exchange/queue declaration → publish/consume (go/send.go)
5. Update language-specific README with pattern explanation and run instructions (go/README.md)

Add a new programming language

1. Create new language directory at repository root (e.g., python/, javascript/) (go)
2. Create language-specific build/package file (go.mod, project.clj, pubspec.yaml, package.json, etc.) (clojure/project.clj)
3. Create README.md with setup instructions and tutorial overview (go/README.md)
4. Implement all 6 tutorial patterns: send/receive, new_task/worker, emit_log/receive_logs (3 variants), rpc_client/server (go/send.go)
5. Update root README.md to reference new language implementation (README.md)

Update dependencies across all implementations

1. Update language-specific dependency file (go.mod for Go, project.clj for Clojure, etc.) (go-amqp/go.mod)
2. Test affected tutorial files in that language (go/send.go)
3. Verify Dependabot configuration will auto-detect future updates (.github/dependabot.yml)

• RabbitMQ (AMQP 0.9.1 + 1.0) — Industry-standard message broker; tutorials teach both legacy and modern AMQP versions for backward compatibility
• Multi-language approach (Go, Clojure, C++, .NET, Dart, Python, Ruby, etc.) — Demonstrates AMQP patterns are language-agnostic; enables developers to learn in their preferred language
• Docker dev container (.devcontainer/) — Ensures consistent RabbitMQ + runtime environment across all contributor machines and CI/CD pipelines
• GitHub Actions + Dependabot — Automates dependency updates and testing for 600+ tutorial files across multiple languages

• Each language maintains independent, self-contained implementations

  • Why: Avoids coupling between language tutorials; allows learners to study code without understanding other languages
  • Consequence: Code duplication across 10+ language directories; higher maintenance burden when updating patterns

• Minimal production-ready features (error handling, retry logic, monitoring)

  • Why: Tutorials focus on core AMQP patterns; excessive production code would obscure learning objectives
  • Consequence: Code cannot be used directly in production; developers must add resilience layers

• Localhost-only RabbitMQ connection

  • Why: Simplifies setup for beginners; no authentication or remote configuration needed
  • Consequence: Tutorials must be adapted for cloud deployments (VPC, TLS, credentials management)

• No shared test framework or integration tests

  • Why: Test infrastructure is language-specific; centralizing would constrain language choices
  • Consequence: Each language maintainer must verify pattern correctness independently

• Production-grade error handling, retries, or circuit breakers
• Authentication, authorization, or encryption setup
• Distributed tracing, monitoring, or observability
• Performance optimization or benchmarking
• Cloud deployment (AWS, Azure, GCP) examples
• Integration with message serialization frameworks (Protobuf, Avro)
• Testing framework unification across languages

RabbitMQ must be running on localhost:5672 with default credentials (guest/guest) before executing any example—failures are silent timeouts if broker is unreachable. Language-specific gotchas: (1) Java examples require manual classpath setup (-cp .:lib/*) if using direct javac instead of Maven/Gradle, (2) Python examples depend on pika version compatibility (old versions may drop features), (3) Go examples require go 1.24.0+ (stated in go.mod), (4) C++ examples need CMake 3.x and an external AMQP C library, (5) Rust examples have two separate implementations (amqprs vs. Lapin) with different async models—picking wrong one causes API mismatches. No unified test suite, so running examples is the only validation. Docker Compose is not provided, requiring manual RabbitMQ container management.

• AMQP (Advanced Message Queuing Protocol) — All examples in this repo implement AMQP semantics; understanding this protocol is required to interpret producer/consumer behavior across languages
• Message Exchange Types (Direct, Fanout, Topic) — Core pattern variations taught across emit_log, emit_log_direct, emit_log_topic examples; mastering these determines when/how to route messages in real systems
• Message Acknowledgment (ACK) and Quality of Service (QoS) — Worker and queue examples depend on manual/auto ACK settings; misunderstanding this causes message loss or duplicate processing in production
• RPC (Remote Procedure Call) with Correlation IDs — rpc_client.* and rpc_server.* examples implement request-reply over AMQP; understanding correlation ID matching is critical for async RPC implementation
• Binding Keys and Routing Keys — Topic and direct routing examples use these to filter messages at the broker level; core concept for designing scalable pub/sub systems
• Connection Pooling and Channel Management — Each language port handles AMQP connection/channel lifecycle differently; production deployments require understanding connection reuse and thread safety per language
• Dead Letter Exchanges (DLX) — Not explicitly covered in tutorials but implicit in error-handling discussions; understanding DLX is essential for resilient message processing patterns beyond basic examples

• rabbitmq/rabbitmq-server — The actual RabbitMQ message broker that all these tutorials depend on; this repo is purely client-side examples against that server
• rabbitmq/amqp-go-client — Official Go AMQP client library used by /go examples; main reference for Go-specific RabbitMQ features
• pika/pika — Python AMQP client library (http://pika.readthedocs.io) that backs all /python examples; core dependency for Python learners
• rabbitmq/rabbitmq-python-client — Legacy Python AMQP client; context for why modern tutorials use pika instead
• doctrine/rabbitmq-bundle — Symfony PHP integration layer building on the php-amqplib used in /php examples; ecosystem companion for PHP developers scaling beyond tutorials

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add Go AMQP 1.0 tutorial implementations to match language parity

The repo has go.mod with Azure/go-amqp and rabbitmq-amqp-go-client dependencies, but no go-amqp directory exists in the file structure. While go-0.10 and go-0.11 implementations likely exist (not shown), creating a dedicated go-amqp directory with AMQP 1.0 protocol examples would provide feature parity with other languages (cpp, dart, dotnet-amqp, clojure, common-lisp) and showcase the newer AMQP 1.0 client library.

• [ ] Create go-amqp/ directory following the pattern of other language directories
• [ ] Implement send.go, receive.go, new_task.go, worker.go matching tutorial 1-3
• [ ] Implement emit_log.go, receive_logs.go, emit_log_direct.go, receive_logs_direct.go, emit_log_topic.go, receive_logs_topic.go for pub/sub tutorials
• [ ] Implement rpc_server.go and rpc_client.go for RPC tutorial
• [ ] Add go-amqp/README.md with setup instructions and Azure/go-amqp client library reference
• [ ] Ensure all examples follow go-amqp v1.5.1 API conventions

Add GitHub Actions CI workflow to validate all language implementations

The repo has .github/dependabot.yml for dependency updates but no CI workflow file exists. With 8+ language implementations (Clojure, Common Lisp, C++, Dart, dotnet-amqp, Go, Java, Node.js, Python, etc.), a matrix-based CI workflow would catch breaking changes early, validate RabbitMQ connectivity for each language, and ensure tutorials remain runnable.

• [ ] Create .github/workflows/ci.yml with Docker Compose service to run RabbitMQ
• [ ] Add build/test jobs for each language directory (clojure, common-lisp, cpp, dart, dotnet-amqp, go-amqp, etc.)
• [ ] For compiled languages (cpp, dotnet-amqp), add build validation steps
• [ ] For interpreted languages (python, node, clojure, dart), add dependency check and syntax validation
• [ ] Add a smoke test that verifies at least one send/receive example can connect to RabbitMQ
• [ ] Configure job to fail if any language implementation cannot build or connect

Add publisher_confirms.cpp pattern implementation to remaining languages

The cpp directory contains publisher_confirms.cpp (a tutorial on reliable publishing), but this pattern is missing from most other language directories. Implementing publisher confirms tutorials in Python, Node.js, Java, Dart, and Clojure would provide consistency and teach a critical production pattern across all supported languages.

• [ ] Create publisher_confirms examples in python/, nodejs/, java/, dart/, and clojure/ directories
• [ ] Each implementation should demonstrate synchronous and asynchronous publisher confirms
• [ ] Add to appropriate language README.md files explaining the publisher confirms pattern
• [ ] Ensure examples follow the same message flow as cpp/publisher_confirms.cpp
• [ ] Validate that examples use each language's idiomatic async/callback patterns

• Add a missing tutorial language port (e.g., implement all 6 tutorial patterns for a new language like OCaml or Nim) by copying the pattern from an existing complete port and adapting to language idioms.
• Create a Compose file (docker-compose.yml) in the root that spins up RabbitMQ + monitoring UI (Management Plugin) and a dev setup script, reducing onboarding friction noted in the prerequisites section.
• Standardize error handling and logging across all language ports (currently inconsistent)—add a 'best practices' section to each language README documenting exception handling for broker timeouts, connection failures, and message parsing errors with example code.

This RabbitMQ tutorials repository has a generally sound security posture for educational material. The codebase is primarily example code rather than production systems, which appropriately reduces security complexity. Key observations: (1) Dependency management appears reasonable with Dependabot configured for the Go module; (2) No obvious hardcoded secrets or credentials detected in file structure; (3) No SQL injection or XSS vectors identified (expected for RabbitMQ client tutorials); (4) Docker infrastructure is present but requires review of actual configurations. Main concerns are typical for tutorial code: potential for developers to copy patterns with hardcoded localhost connections and default credentials into production. The score is moderate because this is educational material where some insecure patterns are intentional for simplicity, but documentation could better emphasize security best practices for production deployments.

• Medium · Hardcoded RabbitMQ Connection to Localhost — README.md, tutorial code files across all language directories. The README explicitly states that all tutorials require 'a RabbitMQ node running on localhost with stock (default) settings'. This suggests tutorial code likely contains hardcoded localhost connections without configurable endpoints. While appropriate for tutorials, this pattern should not be replicated in production code and indicates potential for credential/connection string hardcoding in actual implementations. Fix: Ensure tutorial code prominently documents the need to externalise connection parameters (host, port, credentials) via environment variables or configuration files. Add warnings in documentation against copy-pasting tutorial code directly to production.
• Low · Default RabbitMQ Credentials in Examples — All tutorial implementations across language directories (clojure, cpp, dart, dotnet-amqp, etc.). The README mentions using RabbitMQ with 'stock (default) settings', which typically means using default guest/guest credentials. While acceptable for development tutorials, this could lead to developers using weak credentials in test/staging environments that might be exposed. Fix: Add explicit documentation and code comments warning developers to change default credentials before deploying to any networked environment. Include examples showing how to use environment variables for credentials.
• Low · Missing Security Headers in Devcontainer Configuration — .devcontainer/Dockerfile, .devcontainer/devcontainer.json. The .devcontainer/Dockerfile and devcontainer.json files are present but not fully reviewed. Development containers should ensure they don't expose unnecessary ports or run with excessive privileges. Fix: Review Dockerfile for: non-root user execution, minimal base image, no unnecessary port exposure. Ensure devcontainer.json doesn't grant excessive capabilities or mount sensitive host directories.
• Low · Node.js Library Script in Devcontainer — .devcontainer/library-scripts/node-debian.sh. The presence of .devcontainer/library-scripts/node-debian.sh suggests automated installation scripts. These could potentially be vulnerable if they install packages from untrusted sources or don't verify checksums. Fix: Verify that any automated installation scripts use package managers with signature verification. Pin specific versions of dependencies rather than using latest/wildcard versions.
• Low · Dependency Version Management in Go Module — go-amqp/go.mod. The go.mod file uses specific versions for direct dependencies but indirect dependencies are present. The go 1.24.0 version specification is unusual (as of standard Go releases), and version pinning practices should be verified to prevent supply chain attacks. Fix: Verify all dependency versions are stable and from trusted sources. Use 'go mod verify' regularly to detect tampering. Consider using 'go mod tidy -v' to audit dependencies and implement automated dependency scanning tools like Dependabot (already present - ensure it's configured correctly).

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.