This repository was archived by the owner on May 13, 2026. It is now read-only.
fix(query): resolve descriptive_name correctly and surface ambiguity as 409 - #1028
Merged
Conversation
…as 409 PR #975 added a descriptive_name resolver to `/api/query`, `/api/mutation`, and `/api/feed`, but it was silently broken: `processor.get_schema(name)` does its own descriptive_name fallback internally, so the resolver's first check (`is_some()`) succeeded for descriptive labels and returned them unchanged. Downstream fold_db then emitted "not found as schema or view", which is exactly the bug the dogfooding session on 2026-05-13 observed for "Contacts", "Apple Notes", etc. Fix: drive the resolver off `processor.list_schemas()` and check the canonical-name match against the active-schema set directly (a name match on `s.schema.name`). Descriptive_name fallback then collects every match; 1 → resolve to canonical, 2+ → surface as `SchemaResolution::Ambiguous`. `/api/query` and `/api/mutation` now map ambiguity to a structured 409 with `{ ambiguous_schemas: [<hash1>, ...] }` so the caller can pin a future query to one canonical hash — the duplicate-Approved-schema case the running prod hits (2x Contacts, 2x CalendarEvent, 2x Photography). Non-HTTP callers (Lambda / `handlers::query::execute_query`, `mutation::execute_mutation_from_components`, `feed`) collapse ambiguity to 400 via `SchemaResolution::into_canonical_or_err()` for backward compatibility. Tests: - `tests/query_descriptive_name_test.rs::query_accepts_descriptive_name` and `mutation_accepts_descriptive_name` were silently failing — both now pass. - New route-level tests cover happy-path descriptive_name resolution (200) and ambiguous-name 409 for both query and mutation. Out of scope: the duplicate-schema problem itself (separate kanban task) and README updates that teach the descriptive_name pattern. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Summary
POST /api/queryandPOST /api/mutationnow accept a schema'sdescriptive_name(e.g."Contacts","Apple Notes") inschema_name— the resolver added in PR feat(query): accept descriptive_name in /api/query (alongside hash) #975 was silently broken and shipping the same "not found as schema or view" error on descriptive labels.{ ambiguous_schemas: [<hash1>, …] }body, not a silent pick.folddb query <NAME>inherits the fix; route-level tests cover both happy and ambiguous paths for query and mutation.What was broken
crate::handlers::schema_resolution::resolve_schema_nameshort-circuited viaprocessor.get_schema(name).is_some(). ButOperationProcessor::get_schemaitself does a descriptive_name fallback internally, sois_some()was true for descriptive labels too — and the resolver returned the descriptive label unchanged. Downstream fold_db then emitted'<descriptive label>' not found as schema or view. The existing integration testsquery_accepts_descriptive_nameandmutation_accepts_descriptive_namewere silently failing onmainbecause of this; they now pass.Test plan
cargo clippy --workspace --all-targets -- -D warningscargo nextest run --workspace --lib(1090 passed)cargo test --workspace --doccargo test --test query_descriptive_name_test(the 2 silently-broken ones in this file now pass)src/server/routes/query.rs:execute_query_accepts_descriptive_name_with_200execute_query_returns_409_on_ambiguous_descriptive_nameexecute_mutation_accepts_descriptive_name_with_200execute_mutation_returns_409_on_ambiguous_descriptive_namesrc/server/static-react/src/types/openapi.tsfor the 409 responseOut of scope
🤖 Generated with Claude Code