fix(query): pipeline resolver — handle column-keyed row objects#13
Merged
Conversation
PR #12's selectIDNamePairs assumed rows came back as positional arrays ([]any aligned with `columns`), but the live hosted warehouse query API returns rows as column-keyed maps (map[string]any with "id" and "name" keys). The unit-test fixture also returned positional arrays, so the mismatch slipped through — verified against prod by running: topline --agent query audit --pipeline 'flex triage' ... which returned `no pipeline matched ... Available pipelines: (none found)` even though `SELECT id, name FROM pipelines` returned rows fine. Fix - selectIDNamePairs now switches on row type: - map[string]any: read row["id"] / row["name"] by column name. - []any: read by positional index (preserved for parity with any deployment that returns array rows). - Test fixture in pipelineLookupServer rewritten to emit the real column-keyed object shape ({"id":"...","name":"..."}), so the resolver tests now exercise the actual wire format. Verified live: `topline --agent query audit --pipeline 'flex triage' ...` resolves to bna6e9DoPgRchNsjeYS3 (Sales - Flex - Triage) and runs the audit cleanly. All existing resolver tests still pass.
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.
Why
Follow-up to #12. The v1.6.2 pipeline-name resolver shipped with a row-shape mismatch that made it silently fail against the real hosted warehouse:
SELECT id, name FROM pipelinesreturns rows fine; the resolver simply didn't recognize the row shape.Root cause
The hosted warehouse query API returns rows as column-keyed maps:
{"columns": ["id","name"], "rows": [{"id":"bna6...","name":"Sales - Flex - Triage"}]}But
selectIDNamePairsassumed positional arrays ([]anyaligned withcolumns). Every row failed ther.([]any)type assertion and got silently skipped, leaving the resolver to report "(none found)".The unit-test fixture in
pipelineLookupServeralso emitted positional arrays, so the mismatch slipped through CI.Fix
selectIDNamePairsnow switches on row type:map[string]any→ readrow["id"]/row["name"]by column name.[]any→ read by positional index (preserved for parity with any deployment that returns array rows).Verified live
Resolves cleanly to
bna6e9DoPgRchNsjeYS3(Sales - Flex - Triage) and runs the audit.All existing resolver tests still pass.