[Bug]: GraphQL fields listed after a fragment spread are silently dropped

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#3,861 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 7 jours

@hippi345 y travaille déjà.

Depuis le 17/10/2026.

  • #3862 par @hippi345 — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
76/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
azure, csharp, graphql
Domaine
api, databases

Piste de recherche

Commencez dans src/Core/Resolvers/Sql Query Structures/SqlQueryStructure.cs et lisez AddGraphQLFields, en vous concentrant sur la manière dont les branches de propagation de fragment et de fragment inline traitent les sélections restantes. Vérifiez les tests GraphQL existants pour les sélections de fragments et ajoutez des tests pour les champs qui suivent les deux formes de fragment. Le travail est terminé lorsque les champs scalaires et de relation qui suivent un fragment sont inclus dans la requête SQL et renvoyés, tandis que le comportement existant des fragments continue de fonctionner.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug triage

Note: The below was written and discovered by claude but I have independently verified it myself as well.

What happened?

When a selection set contains a fragment spread (or inline fragment), every field listed after it in the same selection set is never added to the SQL query. Those fields come back null with no error. This applies to both scalar fields and relationship fields.

Repro:

query {
  book_by_pk(id: 1) {
    ...bookFields
    title
    publishers { name }
  }
}

fragment bookFields on book { id }

Expected: id, title and publishers are populated.
Actual: id is populated; title and publishers are null.

The same query works if ...bookFields is moved to the end of the selection set, or removed.

Cause: in SqlQueryStructure.AddGraphQLFields, both the FragmentSpread and the InlineFragment branches recurse into the fragment and then return;. That exits the foreach over the remaining selections. These look like they should be continue;:

https://github.com/Azure/data-api-builder/blob/main/src/Core/Resolvers/Sql%20Query%20Structures/SqlQueryStructure.cs (the two return; statements after the recursive AddGraphQLFields calls)

The return; dates from #1236, which added fragment support for #1235. The Cosmos path (GenerateQueryColumns) iterates over every selection and isn't affected.

Version

2.1.5

What database are you using?

Azure SQL

What hosting model are you using?

Container Apps

Which API approach are you accessing DAB through?

GraphQL

Relevant log output
Code of Conduct
  • I agree to follow this project's Code of Conduct
Langage dominant
C#
Étoiles
1.5k
Forks
380
Merge moyen
4 j 10 h
PR mergées (30 j)
7

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Azure/data-api-builder

Toutes les issues de Azure/data-api-builder

Issues similaires

Plus d'issues C#

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.