[Bug]: external plugin drivers cannot receive a full connection URI (mongodb+srv rejected, then decomposed)

[Robbyfuu]

Describe the bug

External plugin drivers cannot receive a full connection URI. Two independent gaps in src/utils/connectionStringParser.ts combine to make SRV-based drivers (MongoDB Atlas, and any future driver whose scheme carries semantics) unusable.

Gap 1 — the protocol is rejected

buildProtocolRegistry only registers two things per driver: normalizeProtocol(driver.id) and the protocol extracted from capabilities.connection_string_example. A plugin whose id is mongodb-atlas therefore only registers mongodb-atlas://. Pasting a real Atlas URI fails at connectionStringParser.ts:171:

Unsupported database driver: mongodb+srv. Supported: mongodb-atlas, mysql, postgres, postgresql, sqlite

PROTOCOL_ALIAS_GROUPS is a hardcoded list (postgres/postgresql, mysql/mariadb, sqlite/sqlite3), so a plugin cannot register an alias pair such as mongodb + mongodb+srv even by declaring an example — the example only registers one of the two.

Gap 2 — the URI is destroyed even when the protocol is accepted

Once parsing succeeds, parseConnectionString decomposes the URI into discrete fields (connectionStringParser.ts:200-228) and toConnectionParams forwards only those:

return {
  driver: parsed.driver,
  host: parsed.host,
  port: parsed.port,
  username: parsed.username,
  password: parsed.password,
  database: parsed.database,
};

The scheme and the entire query string are discarded. For mongodb+srv:// this is not recoverable:

• mongodb+srv mandates a DNS SRV lookup to discover the replica-set members. A bare hostname with no port is not a valid substitute — the driver has no way to know it should resolve SRV records.
• Atlas URIs carry retryWrites, w=majority, authSource, replicaSet and appName in the query string. All are dropped.
• url.port is empty for SRV URIs, so port arrives as undefined and the plugin falls back to default_port (27017), which is wrong for a sharded Atlas cluster.

The observable result is that a connection can appear to be established while database enumeration returns nothing, because the reconstructed connection no longer points at the real cluster.

Grepping current main (39f5ab2) confirms there is no path that preserves the original string — there is no connection_uri / full_uri field anywhere in src-tauri/src or src/utils.

To Reproduce

1. Install an external plugin driver that accepts a full URI. I used a MongoDB Atlas plugin whose manifest.json declares "id": "mongodb-atlas", "default_port": 27017 and no connection_string_example.
2. Open New Connection and paste a standard Atlas connection string:

   mongodb+srv://user:pass@cluster0.xxxxx.mongodb.net/mydb?retryWrites=true&w=majority&appName=Cluster0
   

3. The modal rejects it with Unsupported database driver: mongodb+srv.
4. Work around gap 1 by adding "connection_string_example": "mongodb+srv://user:pass@host/db" to the plugin manifest so the protocol registers.
5. Paste the same URI again. It now parses, but the plugin receives only host=cluster0.xxxxx.mongodb.net, port=undefined, database=mydb — no SRV scheme, no query parameters.
6. The connection does not resolve to the real cluster and databases fail to load.

OS Version

macOS 26.4 (25E246), arm64

Tabularis Version

v0.14.0 (also verified against main @ 39f5ab2)

Relevant Log Output

Unsupported database driver: mongodb+srv. Supported: mongodb-atlas, mysql, postgres, postgresql, sqlite

---

Suggested direction

The core need is that a plugin should be able to declare "I take the raw connection string, do not decompose it", and the host should carry that string through to the driver over JSON-RPC.

Roughly:

1. A capability flag (e.g. connection_string_passthrough) that makes parseConnectionString skip decomposition and preserve the original URI verbatim.
2. A connection_uri field on the connection model, forwarded to the external plugin on connect.
3. Allow plugins to declare multiple protocols rather than deriving a single one from driver.id plus one example, so alias pairs like mongodb / mongodb+srv work.

Because the URI embeds credentials, it should be treated as a secret: stored in the OS keychain rather than in connections.json, with the cached secret rolled back if persistence fails. A transient URI is acceptable for Test Connection, but a saved connection should require keychain availability.

I have a prototype of this against the v0.14.0 codebase. It predates the capability-driven protocol registry that main now has, so it needs to be reworked to fit the current architecture, and I have not yet verified end-to-end that databases enumerate correctly with it. I am happy to open a PR once it is rebased and properly verified — let me know if the direction above is one you would accept.

[debba]

Hi,
feel free to create a PR for it

[Robbyfuu]

Following up with a correction and some additional findings after testing this end to end. Two things I got wrong or left out in the original report.

1. There is an official workaround, so the severity is lower than I implied

The first-party mongodb plugin already ships settings that make Atlas work without any code change:

setting	value
srv	true
tls	true
auth_source	admin

With those set, my Atlas cluster connects and enumerates databases correctly. Notably it connects with the Connection String field left empty and host/port still at cluster0.xxxxx.mongodb.net:27017 — so the srv flag alone is what drives it. strings on the plugin binary confirms it embeds the full MongoDB Rust driver with complete SRV support (mongodb+srv, srvServiceName, srvMaxHosts).

So this is not "Atlas is unsupported". It is "the connection string field cannot express it".

2. The more actionable defect: plugin settings are global, not per connection

src-tauri/src/config.rs:55:

pub plugins: Option<HashMap<String, PluginConfig>>,

The map is keyed by plugin id only, and the UI surfaces it through a global PluginSettingsPage / PluginSettingsModal keyed by pluginId. ConnectionParams has no plugin-settings field, so nothing is stored per connection.

That means the workaround above does not compose. Turning on srv for an Atlas cluster turns it on for every MongoDB connection, so an Atlas cluster and a local mongodb://localhost:27017 cannot coexist. Same for tls, auth_source and replica_set.

3. Warning: fixing the protocol rejection alone would make this worse

The obvious minimal fix is to add ["mongodb", "mongodb+srv"] to PROTOCOL_ALIAS_GROUPS in connectionStringParser.ts. Please do not do only that.

Today the user gets a loud, correct error:

Unsupported database driver: mongodb+srv. Supported: mariadb, mongodb, mongodb-atlas, mysql,
postgres, postgresql, redis-rust, sqlite, sqlite3

If the alias is registered without also preserving the scheme, parseConnectionString would accept the URI, decompose it, discard mongodb+srv, and persist host: cluster0.xxxxx.mongodb.net, port: 27017. Since Atlas SRV hostnames have no A record, that connection then fails at DNS resolution:

Server selection timeout: No available servers.
Servers: [ { Address: cluster0.xxxxx.mongodb.net:27017, Type: Unknown,
  Error: I/O error: failed to lookup address information: nodename nor servname provided } ]

That trades a clear validation error for a connection that is silently misconfigured and saved to disk. It is the exact failure mode I spent a long time misdiagnosing before finding the srv setting. Gap 1 should not land without Gap 2.

Suggested ordering

1. Add a per-connection plugin settings store so srv / tls / auth_source / replica_set can differ per connection. This alone makes Atlas fully usable and is independently valuable for every plugin.
2. Then let the connection string carry the scheme through — either via a passthrough capability, or by mapping a parsed mongodb+srv:// onto the plugin settings it implies (srv=true, plus authSource / replicaSet from the query string).

Happy to take a stab at either if the direction looks right, though as noted I would want to rebase properly against current main first.

[debba]

Yes, btw another way could be using UI slots which are defined here:

https://github.com/TabularisDB/tabularis/blob/main/plugins/PLUGIN_GUIDE.md

In that case, nothing should be changed in Tabularis app, but directly on the plugin .

Wdyt?

[Robbyfuu]

I went deep on the slot idea before answering, because I really like the direction — but as the slot system stands today it cannot carry this use case on its own. Three concrete obstacles, all in current main:

1. The slot never renders for this plugin. connection-modal.connection_content is gated on no_connection_required (NewConnectionModal.tsx:563-568, rendered only in the API-based branch around line 1903). The mongodb plugin has a normal connection form, so a contribution from it would never mount. Relaxing that gate is itself a change in Tabularis — so "nothing changes in the app" unfortunately doesn't hold.

2. There is nowhere to put the value. The only persistence available to a slot component is usePluginSetting(pluginId) — one value per plugin, global, written to config.json in plaintext. Two Atlas clusters would overwrite each other, and a full URI embeds credentials, so plaintext config.json is exactly where it must not live. This is the same limitation that keeps the plugin's existing global uri setting from solving it.

3. The slot does not know which connection it is editing. The context for that slot carries { driver, database, onDatabaseChange, connectionName } — no connectionId, and for a brand-new connection no id exists yet, so the component cannot even namespace a per-connection key on its own.

So my honest answer to "wdyt": your idea plus a small host contract, rather than either alone.

• Host side: a per-connection connection_uri on ConnectionParams, stored in the OS keychain (never connections.json), forwarded verbatim to the driver. I had already drafted this before reading your comment — feat(connections): forward raw connection URIs to plugin drivers #495, opened as a draft.
• Plugin side (your suggestion): the connection UI moves into the slot. The slot context already ships a form writer (onDatabaseChange); adding an equivalent writer for the URI and relaxing the render gate would let each plugin own its connection UX entirely, while the host keeps the two things only it can provide: per-connection secret storage and transport.

Under that split, the generic modal changes in #495 become the fallback UI, and any plugin can replace them with its own slot content — full control for plugins, security contract stays in the app.

Happy to split or reduce #495 if you prefer smaller steps (transport + keychain first, UI second). I'm also updating the MongoDB plugin to declare and consume the capability, so the whole loop gets exercised against a real Atlas cluster rather than staying theoretical.

[Robbyfuu]

Quick map of the moving pieces that came out of this issue, so it's clear what each one is for and what depends on what:

Piece	What it is	Depends on
#495 (draft)	Host-side URI passthrough: connection_uri capability, per-connection keychain storage, transport to the plugin	Nothing — this is the core
#496	Registry entry for the MongoDB URI plugin (repo, release v0.2.0, 5 platforms)	Nothing — works today on 0.15.0 as a standard host/port MongoDB driver
Plugin v0.2.0	Consumes connection_uri verbatim; already declares the new capabilities	#495 only for the URI feature to activate

Why the host PR is needed at all — the plugin cannot do this alone: the plugin only receives what the host sends. Today the host rejects mongodb+srv://, decomposes any URI it does accept (dropping the scheme and query string that SRV needs), and has no per-connection place to store the URI nor a keychain path for it. None of that is reachable from plugin code, and the same limitation applies to the UI-slots route — the slot for the connection modal only renders for no_connection_required drivers, its only storage is the global plugin settings (plaintext config.json), and its context has no connectionId.

Deliberately, nothing blocks anything:

• feat(registry): add MongoDB URI plugin #496 can land independently — the plugin degrades gracefully on hosts without passthrough. Its manifest omits connection_string_example on purpose, so pasting an Atlas URI on current Tabularis keeps failing loudly instead of being decomposed and silently saved broken.
• feat(connections): forward raw connection URIs to plugin drivers #495 can land independently — the generic modal flow works with any plugin that later declares the capability.
• If you prefer a different host design (per-connection plugin settings, or slots once the gate/storage/context gaps are addressed), the plugin adapts trivially — its side of the contract is one field read, already tested.

Everything is verified end to end against a live Atlas cluster (evidence in the #495 thread). Happy to reshape any of it if you want a different direction.