87 lines
4.5 KiB
Markdown
87 lines
4.5 KiB
Markdown
# RabbitMQ local integration evidence — 2026-09-18
|
|
|
|
> Historical record: this verifies the former tenant-queue `--consume --tenant-key` path, which F03 removed. It is not current runtime or protocol evidence; current local V3 evidence is [here](f03-local-task-runtime-v0.1.md). No external broker compatibility is implied.
|
|
|
|
## Scope
|
|
|
|
This is an isolated local Docker broker test only. It is not a SaaS broker,
|
|
production acceptance, or an authorization to connect to an external broker.
|
|
The container was removed by the test script on exit; credentials were
|
|
randomized and not recorded.
|
|
|
|
## Run
|
|
|
|
- command: `make mq-integration-local`
|
|
- image: `rabbitmq:4.1-management-alpine`
|
|
- local image ID: `sha256:fcc273cebb0880ec25845c9bfd97687122ac9cc391538f053cb5873f4181f35f`
|
|
- adapter: `OpenWithPrefetch(..., 1)`
|
|
- tests: `go test -tags=integration ./internal/mq ./internal/dispatcher`
|
|
- result: passed
|
|
|
|
The tests exercised a fresh tenant queue and its durable DLQ, publisher
|
|
confirm, routing-key preservation, manual ACK, permanent rejection/dead-letter
|
|
routing, and a second consumer after cancellation. The Dispatcher integration
|
|
case additionally delivered the contract fixture through the tenant queue,
|
|
persisted inbox/task/outbox state in SQLite, published the resulting event,
|
|
and verified `task_status=accepted` and `outbox_status=published`. Consumer
|
|
tags are unique and are explicitly cancelled so a stopped consumer cannot
|
|
retain later deliveries.
|
|
The broker readiness gate uses RabbitMQ's `check_running`; a ping alone is not
|
|
sufficient for application readiness.
|
|
|
|
## ECS candidate connection smoke
|
|
|
|
After the local test, the same pinned image digest
|
|
`sha256:fcc273cebb0880ec25845c9bfd97687122ac9cc391538f053cb5873f4181f35f`
|
|
was transferred to the owner-authorized Debian ECS because the host could not
|
|
pull Docker Hub directly. It was run as an isolated loopback-only disposable
|
|
broker with a randomized non-recorded credential and removed after the test.
|
|
The current candidate binary at
|
|
`/opt/sip-go-agent/sip-go-agent.269a0d2ad350544597a71d3b0869ceb57d57f86defb3fe560e64e75bc052edb6`
|
|
connected successfully:
|
|
|
|
- `dispatcher --mode mock --once` returned `0` and reported `published: 0`.
|
|
- `dispatcher --mode mock --consume --tenant-key deploy-smoke` connected and
|
|
remained waiting for deliveries until the bounded 8-second smoke timeout
|
|
(`124`); it emitted no connection or configuration error.
|
|
- A second bounded run published the approved contract fixture
|
|
`examples/call.execute.json` through the broker management API. The broker
|
|
returned `routed: true`; the deployed candidate consumed it with
|
|
`tasks=1`, `inbox=1`, and `outbox=1`, then a separate deployed candidate
|
|
`dispatcher --mode mock --once` returned `0` with `published: 1`.
|
|
- Final isolated SQLite state was `task_status=accepted` and
|
|
`outbox_status=published` for one row. The disposable broker container and
|
|
fixture were removed after the check; the randomized password was not
|
|
recorded.
|
|
|
|
This proves candidate-to-broker TCP/AMQP authentication, tenant routing,
|
|
SQLite inbox/task/outbox handling, and candidate outbox publication on the ECS
|
|
against a disposable broker. It does not prove SaaS application receipt or an
|
|
approved production broker.
|
|
|
|
## Follow-up candidate: consume now flushes outbox
|
|
|
|
The first ECS receipt smoke exposed that the deployed `--consume` path only
|
|
accepted commands and required a separate `--once` process to flush outbox.
|
|
The command was corrected to run a bounded outbox flush loop while consuming,
|
|
with a regression test in `cmd/sip-go-agent/main_test.go`.
|
|
|
|
Candidate SHA-256:
|
|
`14d61e617df1c00a9a0ab372f8baf0b8a67e40cff75fcfb36fb1f9cfb27a0725`.
|
|
With only the candidate `dispatcher --consume` process running, the same
|
|
fixture was published to the isolated tenant queue. The broker returned
|
|
`routed: true`; within one second the candidate persisted `tasks=1`,
|
|
`inbox=1`, `outbox=1`, and `outbox_status=published`. No separate `--once`
|
|
flush process was run. A temporary SaaS-events queue bound to
|
|
`agent-call.events.v1` then received one `agent-call.command.result` message
|
|
(`payload_bytes=472`, `delivery_mode=2`, `content_type=application/json`). The
|
|
temporary broker, queue, and fixture were removed after the check.
|
|
|
|
## Remaining boundary
|
|
|
|
This proves only the local adapter/topology and an isolated ECS candidate
|
|
connection against a disposable RabbitMQ container. It does not prove the
|
|
approved broker version, production ACL/vhost, TLS, network policy, queue
|
|
limits, crash/commit recovery, multi-Dispatcher coordination, SaaS
|
|
application receipt, or P1 capacity/backpressure.
|