Skip to content
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
shiba4life merged 1 commit into
mainfrom
fix/query-by-descriptive-name
May 13, 2026
Merged

fix(query): resolve descriptive_name correctly and surface ambiguity as 409#1028
shiba4life merged 1 commit into
mainfrom
fix/query-by-descriptive-name

Conversation

@shiba4life

Copy link
Copy Markdown
Collaborator

Summary

  • POST /api/query and POST /api/mutation now accept a schema's descriptive_name (e.g. "Contacts", "Apple Notes") in schema_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 descriptive_name (multiple Approved schemas share a label — real today on prod: 2x Contacts, 2x CalendarEvent, 2x Photography) now returns 409 with a structured { 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_name short-circuited via processor.get_schema(name).is_some(). But OperationProcessor::get_schema itself does a descriptive_name fallback internally, so is_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 tests query_accepts_descriptive_name and mutation_accepts_descriptive_name were silently failing on main because of this; they now pass.

Test plan

  • cargo clippy --workspace --all-targets -- -D warnings
  • cargo nextest run --workspace --lib (1090 passed)
  • cargo test --workspace --doc
  • cargo test --test query_descriptive_name_test (the 2 silently-broken ones in this file now pass)
  • 4 new route-level tests in src/server/routes/query.rs:
    • execute_query_accepts_descriptive_name_with_200
    • execute_query_returns_409_on_ambiguous_descriptive_name
    • execute_mutation_accepts_descriptive_name_with_200
    • execute_mutation_returns_409_on_ambiguous_descriptive_name
  • Regenerated src/server/static-react/src/types/openapi.ts for the 409 response

Out of scope

  • The duplicate-Approved-schemas problem itself (separate kanban task tracks schema dedup investigation).
  • README updates that teach the descriptive_name pattern (separate task).

🤖 Generated with Claude Code

…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>
@shiba4life
shiba4life enabled auto-merge May 13, 2026 02:31
@shiba4life
shiba4life added this pull request to the merge queue May 13, 2026
Merged via the queue into main with commit 29964b9 May 13, 2026
12 checks passed
@shiba4life
shiba4life deleted the fix/query-by-descriptive-name branch May 13, 2026 02:42
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant