Repository navigation
fix(db): refuse an inline connection with no id before the cache key - #1572
Merged
cevheri merged 5 commits intoOct 7, 2026
Merged
Conversation
getOrCreateProvider computed its cache key ahead of the provider, and providerCacheKey length-frames connection.id, so an inline connection without an id crashed there with a TypeError that the routes answered as a 500 INTERNAL_ERROR. The provider's own validate() already refuses this record with DatabaseConfigError, which test-connection answered as a 400; getOrCreateProvider and acquireExecutionProfileProvider now raise the same refusal before their cache key, so no fallback key is invented for a missing id (libredb#1539)
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Member
|
Hi @niukanen1 whis database are using on libredb-studio (local or cloud) |
Contributor
Author
|
hey! the experience has been good so far, clean codebase and the provider architecture made it easy to navigate. I'm using postgres almost all the time, locally |
# Conflicts: # docs/BACKLOG.md
… seed reset from its new home The id guard was inserted between assertReadOnlyHonoured and its docblock, so the docblock attached to the new function. The route test imported @/lib/seed/config-loader, which libredb#1570 removed on main; it now imports resetCache from @/lib/seed, as the other route tests do.
cevheri
approved these changes
Oct 7, 2026
cevheri
left a comment
Member
There was a problem hiding this comment.
Thanks @niukanen1, this is a clean fix. I ran it live: all ten routes from #1539 now answer 400 CONFIG_ERROR without an id, and nothing is cached or connected. Main moved under the branch, so I pushed a merge plus a small follow-up: the seed import #1570 renamed, and the readOnly docblock back on its function.
mgr-punith
pushed a commit
to mgr-punith/libredb-studio
that referenced
this pull request
Oct 7, 2026
… answer 500 (D244) Found in the review of libredb#1572: resolveConnection calls startsWith on a non-string id before the custom-connection policy check, and withOneShotTunnel hands a missing id to the tunnel pool key before validate() can refuse it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1539
POST /api/db/query,/api/db/healthand/api/db/multi-queryanswered 500INTERNAL_ERROR, "undefined is not an object (evaluating 'value.length')", for an inlineconnectionwith noid, while/api/db/test-connectionanswered the same record 400CONFIG_ERROR, "Connection ID is required".getOrCreateProvidercomputes its cache key before it constructs the provider, andproviderCacheKeylength-framesconnection.id, so a missing id crashed there with aTypeError. The provider's ownvalidate()already refuses this record with aDatabaseConfigError.getOrCreateProviderandacquireExecutionProfileProvidernow raise the same refusal ahead of their cache key, asassertReadOnlyHonoureddoes, so the key never sees a record the provider would refuse and no fallback key is invented for a missing id. Every route that opens a cached provider answers 400CONFIG_ERRORand opens no socket.Tests: the factory refuses a missing id on both entry points before anything is cached; route tests for query, health and multi-query run the real
resolveConnectionand factory and assert the 400 and the empty provider cache; test-connection keeps the 400 it already answered. Red on main, green with the fix.