AI & messaging

10 export-cli — AI tool schema export

gortexa export emits valid JSON schemas in three provider formats for every gortexa.ai.v1-annotated method, without a running server.

for fmt in mcp openai gemini; do
  gortexa export --format "$fmt"      # each emits valid JSON containing the resource tools
done
gortexa export --format nope          # unknown format: non-zero exit, clean failure

All three outputs are locked by golden tests: change the proto and the schemas change, so drift is caught.

11 nats-integration — against a real NATS broker

Starts a real NATS broker from the scenario’s own docker-compose.yaml and runs the mq core-NATS integration tests. With NATS_URL set, the tests connect to the container’s broker rather than an in-process embedded server, and a connection failure fails — a skip counts as failure too.

docker compose -f docker-compose.yaml up -d nats
NATS_URL=nats://127.0.0.1:4222 go test -tags integration -race -count=1 \
  -run 'TestNATS' ./mq/

Asserts TestNATSPubSub and TestNATSQueueGroupLoadBalance PASS — the latter verifies the load-balance semantics of a non-empty group_id (see Configuration).

12 jetstream-integration — against a real JetStream broker

Same structure as 11 with the JetStream driver: the broker starts with -js and the tests use the JETSTREAM_URL env var. Beyond the fanout and load-balance semantics shared with core NATS, it verifies the JetStream-specific at-least-once property — a handler error triggers a delayed redelivery.

docker compose -f docker-compose.yaml up -d nats   # nats:2 with command: ["-js"]
JETSTREAM_URL=nats://127.0.0.1:4222 go test -tags integration -race -count=1 \
  -run 'TestJetStream' ./mq/

Asserts TestJetStreamPubSub, TestJetStreamQueueGroupLoadBalance and TestJetStreamRedeliveryOnHandlerError PASS — the last one pins the at-least-once redelivery (which is why handlers must be idempotent, see Configuration).