fix(ENGKNOW-3566): fail loud on MDR file lookup resolution failure - #132
Merged
gmagnu merged 6 commits intoJul 24, 2026
Merged
Conversation
…ls branch Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
There was a problem hiding this comment.
Pull request overview
This PR tightens MDR-backed mdr:// source resolution in the model driver layer so MDR lookup failures can’t silently degrade into bogus/blank resolved paths; instead, resolution now consistently throws a clear GorResourceException. This aligns MDR resolution behavior with the expectation that dictionary lookups either resolve to a real URL or fail loudly at read time.
Changes:
- Add
MdrServer.validateResolved(...)to enforce “exactly one, non-blank URL” invariants for MDR responses, and route per-document resolution through it. - Harden
resolveMdrUrlandcacheMdrUrlsto avoid propagating/caching blank URLs and to warn-log bulk-cache failures instead of swallowing them. - Add
UTestMdrServerunit tests covering null/blank URL and malformed MDR response shapes.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| model/src/main/java/org/gorpipe/gor/driver/providers/stream/sources/mdr/MdrServer.java | Enforces non-blank resolved MDR URLs, logs bulk resolution failures, and prevents blank URL caching/rewrite. |
| model/src/test/java/org/gorpipe/gor/driver/providers/mdr/UTestMdrServer.java | Adds focused unit tests for validateResolved invariants and regression cases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
bragnarsson
approved these changes
Jul 24, 2026
resolveMdrUrl derived the cache read key from the mdr:// query string (hardcoded direct fallback) but wrote under the server-echoed url_type. With gor.mdr.mdrDefaultLinkType=presigned this wrote under PRESIGNED and read under DIRECT, missing the cache on every resolve and re-hitting MDR. - Add resolveUrlType(URI): derives url_type purely from the request (uri + config default) so read and write keys always match. - getMdrDocument returns the validated MdrUrlsResultItem directly, removing the duplicated urls().get(0) extraction and dead return value. - cacheMdrUrls guards mdrResult.urls()==null so a null-urls bulk response fails loud instead of NPE-ing into the best-effort catch. - Add regression tests for resolveUrlType key derivation. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
gmagnu
deleted the
ENGKNOW-3566-gor-mdr-file-lookup-seem-to-silently-fail-without-error
branch
July 24, 2026 12:28
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.
Problem
ENGKNOW-3566 — a
.gorddictionary lookup over MDR-backed sources could silently fail. A single unresolvable MDR document yielded a degenerate zero-row header (the rawmdr://…cram?env=prdURL as a data value) instead of an error; with two tags it surfaced only as a confusing "header mismatch" error.Root cause
Three silent-failure holes in
MdrServer.java:cacheMdrUrls—catch (Throwable e) {}swallowed every error (auth, outage, bad response), nothing logged.cacheMdrUrls—s.file = u.url()assigned even when the resolved url was null/blank, corrupting the source into a garbage path.getMdrDocument/resolveMdrUrl— never checked the resolved url was non-blank, so a blank url flowed downstream and was opened as a bogus file.Fix — fail loud
Invariant: an
mdr://source resolves to a real, non-blank URL, or the query throws a clearGorResourceException. No blank/unresolved url reaches a reader, no MDR error is swallowed without at least a log record.validateResolved(MdrUrlsResult, URI)— throws on null result,urls().size() != 1, or null/blank url.getMdrDocumentroutes through it.resolveMdrUrlguards its return against a blank cached url.cacheMdrUrlsskips caching/rewrite on a blank resolved url (leavesmdr://for per-source resolution) and logs bulk-cache failures at WARN instead of swallowing. Bulk caching stays best-effort by design — per-source read now fails loud.Scope confined to
MdrServer.java. Exact stg-side reason a document resolves blank is a separate deferred root-cause follow-up.Tests
New plain unit test
UTestMdrServer(no Keycloak/network, not@Ignored): 7 cases covering valid url, null/blank url (regression), null result, null urls list, zero/multiple urls. Full:model:test— 1488 pass, no regression.🤖 Generated with Claude Code