MySQL and SQL Server adapters, outbound delivery to external brokers, and a per-engine guide

[mmalkhatib]

Follows #299. Three things: the two remaining database engines, outbound delivery to a customer's broker, and a guide for a developer meeting one of these databases for the first time.

Along the way it fixes four bugs that were already in releases/r10.0, two of them silent.

---

MySQL and SQL Server adapters

Each is what the plan predicted — a driver, a connection string, a catalog query and a capability list over the existing core — and the core grew two hooks to fit them.

MySQL (serves MariaDB). A database is the schema, so discovery with no schema means the one this connection opened rather than every database on a shared server. No sequences, no MERGE, no RETURNING, no array type; a procedure returns rows by SELECTing, which is the capability PostgreSQL declares false.

SQL Server (serves Azure SQL). The default schema belongs to the login, not the connection, so a named schema is applied per connection through a new OnConnectionOpenedAsync hook — and not fatally, because impersonating a schema's owner is a privilege many service accounts lack. MERGE, OUTPUT and snapshot isolation are all real here.

Outbound: a delivery publishes to the customer's broker

Publish had existed in both bus adapters since they did, and nothing could reach it — the pipeline calls Handle on a handler and neither class had one. An integration could drain a customer's queue and had no way to answer on it. Both adapters now implement IInfolinkHandler and declare [AdapterKind("handler")].

Adding Handle was the smaller half. A broker data source is exclusive — one node holds the connection so the queue is drained once — while a delivery runs on whichever node picked the message up. Publishing would have failed on every node but the owner.

Exclusivity is about consuming, not connecting. When the owned instance is not on this node, the runtime opens a send-only connection instead: the data source's own settings, Consume=false, no Endpoints, its own pool key. It sends and never subscribes, so nothing is processed twice. Same Consume=false the connection test already uses, for the same reason.

Integration-tested on both brokers, including a test that publishes from a host holding no instance for the data source and asserts ownership was not taken on the way past.

Four bugs this found in r10

• Oracle was never validating anything. ODP.NET's Prepare() is a client-side no-op — Oracle compiles at execute time — so the shared statement check passed everything, including select 1 from no_such_table. Its connection test's "prepares every statement" was vacuous. Now uses DBMS_SQL.PARSE, with the PL/SQL frames stripped so the answer is the one ORA- line about the operator's SQL.
• Subscriptions/Get stopped projecting DataSourceId — dropped when an earlier r10 merge took their version of the file, which predates the field. Nothing failed: the API answered null while the row held an id, so the UI read every bound subscription as unbound and saving one from that screen wrote the null back. A test now asserts the read.
• WriteBackHealthAsync keyed a dictionary by InstanceKey, unique for an exclusive instance and not for a pooled one. Publish-only instances made that routine, and a duplicate key took the whole reconcile pass down.
• PostgreSQL claimed MERGE on every version. It arrived in 15; 13 and 14 are still widely run. Capabilities can now be narrowed once the server version is known — unit-tested rather than needing a container per release.

Plus: a never-ANALYZEd PostgreSQL table reported 0 rows (reltuples is -1 there, clamped to zero), so the browser said "no rows" about a table that might hold millions. It says unknown now.

UI

• Brokers appear in the delivery picker with Publish to / Exchange / Routing key, a warning when the endpoint is empty, and a note explaining the send-only connection. Never offered in a receiver — ingress comes through a bus gateway.
• The connection is subscription-wide, so choosing a broker where another stage needs a database now says so, instead of saving something that fails on its first message.
• The schema browser generated SQL that did not parse on half the engines — hardcoded @name and limit 100. Oracle binds :name and takes fetch first; SQL Server puts top before the columns. Each adapter reports its own dialect now. It also drafted call proc(@a) for a procedure, which made a statement whose procedure name was that entire string.
• A statement saved while its adapter was not running was never checked, silently. Both forms now say "Saved, but not checked."
• The SQL hint no longer names two engines out of four — it reports the prefix the adapter declares.

Docs

• New: docs/database-adapters-per-engine.md — for a developer who knows SQL but not this database. One section per engine answering the same five questions: what you must set, how to write a statement, what the types arrive as, how to call a procedure, and what the errors mean. Plus receive-mode selection and a minimal grant per engine.
• external-bus-providers.md gains an Egress section: the properties, why it needed more than a method, and the one thing it cannot do.
• database-adapters-api.md documents both new engines and both bespoke statement checks.
• Per-engine dev warehouses (dev-warehouse-{mysql,sqlserver,oracle}.sql), same schema and rows as the PostgreSQL one so the differences you meet are the real ones.

Verified

475 unit · 431 integration (53 new) · 313 client.

End to end on a live two-node stack: ownership split correct (brokers on one node, relational pools on every node), no duplication with both live, failover with the fencing term incrementing (RabbitMQ 29→30, SQS 1→2), and messages flowing after takeover. All four databases polled through the real pipeline with cursors scoped per subscription.

Notes for review

• A subscription has one dataSourceId, applied to every slot — so one subscription cannot read from a database and publish to a broker. Chain two with ResponseSubscriptionId. The UI now warns rather than letting it save.
• The SQL Server test image is pinned to 2022; Testcontainers defaults to 2019, which has no arm64 build and exits instantly — surfacing as "container is not running", nothing about architecture.
• MySQL's fixture needs --log-bin-trust-function-creators=1: creating a function requires SUPER while binary logging is on.
• Oracle's image is 4.8 GB. Whether CI runs those per PR or nightly is still open.

🤖 Generated with Claude Code

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
37147666	Triggered	Generic Password	2e3d40b	SW.Bitween.IntegrationTests/Fixtures/MySqlDbFixture.cs	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Repository: simplify9/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 0dbfffc6-1e42-49ae-8bc4-a07d0dfbc1b1

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}