Improve GraphQL naming conflict error to identify conflicting entities and operations by Copilot · Pull Request #3722 · Azure/data-api-builder

Copilot · 2026-07-14T21:09:07Z

Why make this change?

When autoentities includes tables whose names differ only by singular/plural form (e.g. dbo.Category and dbo.Categories), DAB fails startup with a vague error that doesn't identify the other conflicting entity, the generated GraphQL names, or how to resolve the conflict.

What is this change?

RuntimeConfigValidator.ValidateEntitiesDoNotGenerateDuplicateQueriesOrMutation: Replaced HashSet<string> operation tracking with Dictionary<string, string> (operation → owning entity). Checks all operations (not short-circuit) to collect every conflicting name, then builds a structured error message including:
- Both conflicting entity names
- Singular/plural type names (for table/view entities)

Before:

Entity dbo_Category generates queries/mutation that already exist

After:

GraphQL naming conflict detected.

Entities:
  dbo_Categories
  dbo_Category

Both entities generate the following GraphQL names:
  Singular type: Category
  Plural type: Categories

Configure distinct GraphQL singular and plural names for one of the entities to resolve this conflict.

How was this tested?

Integration Tests
Unit Tests
- Updated ValidateExceptionForDuplicateQueriesDueToEntityDefinitions helper to verify both conflicting entity names appear in the message
- Updated all 6 existing duplicate-detection test call sites
- Added ValidateAutoEntitiesWithSingularPluralNameCollisionGenerateDuplicateQueries covering the exact dbo.Category / dbo.Categories scenario

Sample Request(s)

N/A — error message improvement only; no API behavior changes.

azure-pipelines · 2026-07-14T21:09:17Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

…ion details

RubenCerna2079 · 2026-07-22T18:06:32Z

@copilot Change the PR so that in the output message we don't include the operation names. Also, if possible we want to keep using the hashset we already used before. Try to change the logic as little as possible from what it was before the changes you made in this PR. The only change should be the error message.

… names, remove ops from message

Copilot · 2026-07-22T18:17:46Z

Copilot Change the PR so that in the output message we don't include the operation names. Also, if possible we want to keep using the hashset we already used before. Try to change the logic as little...

Done in 3a1f2d0. The changes are now minimal:

Reverted back to HashSet<string> with the original bool containsDuplicateOperationNames flag and || short-circuit chain
Added a parallel Dictionary<string, string> operationOwner (only used for error reporting) to identify which entity previously registered the conflicting operations
The error message now shows both conflicting entity names but no operation names

New message format:

GraphQL naming conflict detected.

Entities:
  dbo_Categories
  dbo_Category

Configure distinct GraphQL singular and plural names for one of the entities to resolve this conflict.

azure-pipelines · 2026-08-03T19:09:59Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

RubenCerna2079 · 2026-08-03T19:12:48Z

/azp run

azure-pipelines · 2026-08-03T19:13:17Z

Azure Pipelines: Successfully started running 6 pipeline(s).

Copilot

Pull request overview

Improves configuration-time GraphQL naming conflict diagnostics by augmenting RuntimeConfigValidator.ValidateEntitiesDoNotGenerateDuplicateQueriesOrMutation to track which entity “owns” each generated GraphQL operation name and by updating unit tests to validate the richer error output (including a new unit test for singular/plural auto-entity collisions).

Changes:

Enhanced duplicate GraphQL operation detection to retain the owning entity per operation and emit a more structured conflict message.
Updated existing unit tests to assert the new message shape (prefix + both entity names).
Added a unit test covering dbo.Category vs dbo.Categories (singular/plural collision) behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/Core/Configurations/RuntimeConfigValidator.cs	Tracks operation ownership and builds a more detailed GraphQL naming conflict exception message.
src/Service.Tests/UnitTests/ConfigValidationUnitTests.cs	Updates duplicate-detection assertions and adds a new unit test for singular/plural auto-entity collisions.

RubenCerna2079 · 2026-08-03T19:27:08Z

+                else
+                {
+                    operationOwner[pkQueryName] = entityName;
+                    operationOwner[listQueryName] = entityName;
+                    operationOwner[createMutationName] = entityName;
+                    operationOwner[updateMutationName] = entityName;
+                    operationOwner[deleteMutationName] = entityName;
+                    if (databaseType is DatabaseType.CosmosDB_NoSQL)
+                    {
+                        operationOwner[patchMutationName] = entityName;
+                    }
                }
            }


That should not be possible since the if statement that is used previously to this already checks all the possible operationOwners with the name

Validate only mode can lose operation ownership after an earlier conflict. The || chain mutates graphQLOperationNames incrementally, but operationOwner is populated only in the else block after every Add succeeds.

If an earlier Add succeeds and a later Add fails, the successfully added operation remains in graphQLOperationNames without an owner. Because validate-only mode continues processing, a later entity can collide with that operation and the resulting message omits the actual conflicting entity.

You can repro this with First (Alpha/Shared), Second (Beta/Shared), and Third (Beta/Thirds). Second successfully adds beta_by_pk before failing on Shared, but beta_by_pk is never assigned an owner. Third then conflicts on beta_by_pk, and its recorded error lists only Third instead of identifying Second.

I think we should record ownership immediately for each successful Add, or possibly use the operation-to-owner dictionary as the authoritative duplicate check.

A validate-only regression test should cover this sequence.

…te-graphql-operations' into copilot/fix-duplicate-graphql-operations

RubenCerna2079 · 2026-08-03T21:11:03Z

/azp run

azure-pipelines · 2026-08-03T21:11:31Z

Azure Pipelines: Successfully started running 6 pipeline(s).

RubenCerna2079 · 2026-08-04T20:17:35Z

/azp run

azure-pipelines · 2026-08-04T20:18:00Z

Azure Pipelines: Successfully started running 6 pipeline(s).

aaronburtle · 2026-08-06T07:16:20Z


            if (containsDuplicateOperationNames)
            {
+                string entitiesStr = string.IsNullOrEmpty(conflictingEntityName)


The new message can report non-conflicting names as shared. entityNamesStr always contains the current entity's singular and plural names, but the message labels both values as names generated by both entities regardless of which operation actually collided.

Isn't this incorrect for singular-only and plural-only conflicts, where the other configured name can be different? Likewise for stored-procedure/table conflicts, where the generated operation fields can collide even though the entities singular and plural type names differ.

I'm thinking we should probably track and display only the generated names that actually conflict, and if the implementation can not retain that information, this section should be removed or reworded so it does not claim both entities generate both displayed names.

aaronburtle · 2026-08-06T07:18:03Z

                    || ((databaseType is DatabaseType.CosmosDB_NoSQL) && !graphQLOperationNames.Add(patchMutationName)))
                {
                    containsDuplicateOperationNames = true;
+                    conflictingEntityName =


This lookup reports only the first conflicting owner, but one entity can conflict with different prior entities on different generated names.

For example, if A uses Alpha/Shared, B uses Beta/Betas, and C uses Beta/Shared, C conflicts with B through its singular-derived operations and with A through its plural list query. The current null-coalescing chain reports only B and omits A, so the user may fix the reported conflict only to encounter another startup failure for the same entity.

Could we collect all distinct owners of the conflicting generated names and include every conflicting entity in the diagnostic instead?

I think the first conflicting is enough. The developers can walk through all errors one by one, until they succeed. It would be a lot of heavy lifting to check for all conflicting errors.

aaronburtle

Looks good once comments are addressed!

Initial plan

65cacb3

Copilot AI assigned Copilot and RubenCerna2079 Jul 14, 2026

Copilot AI linked an issue Jul 14, 2026 that may be closed by this pull request

[Known Issue]: Autoentities fail when table names generate duplicate GraphQL operations #3700

Open

Copilot started work on behalf of RubenCerna2079 July 14, 2026 21:09 View session

Improve GraphQL naming conflict error messages with entity and operat…

7803d3d

…ion details

Copilot AI changed the title ~~[WIP] Fix autoentities conflict with duplicate GraphQL operations~~ Improve GraphQL naming conflict error to identify conflicting entities and operations Jul 14, 2026

Copilot finished work on behalf of RubenCerna2079 July 14, 2026 21:25

Copilot AI requested a review from RubenCerna2079 July 14, 2026 21:25

Copilot started work on behalf of RubenCerna2079 July 22, 2026 18:07 View session

Simplify conflict error: use HashSet + operationOwner dict for entity…

0de482c

… names, remove ops from message

Copilot finished work on behalf of RubenCerna2079 July 22, 2026 18:18

RubenCerna2079 and others added 2 commits August 3, 2026 00:06

Fix error message

7d9ce09

Merge branch 'main' into copilot/fix-duplicate-graphql-operations

644df24

RubenCerna2079 marked this pull request as ready for review August 3, 2026 19:09

Copilot AI review requested due to automatic review settings August 3, 2026 19:09

RubenCerna2079 requested review from Alekhya-Polavarapu, Aniruddh Munde (Aniruddh25), Jerry Nixon (JerryNixon), aaronburtle, Anusha Kolan (anushakolan), rusamant, Sourabh Jain (sourabh1007), Souvik Ghosh (souvikghosh04), Stuart Padley (stuartpa) and vadeveka as code owners August 3, 2026 19:09

RubenCerna2079 added the 2.1 label Aug 3, 2026

RubenCerna2079 added this to Data API builder Aug 3, 2026

RubenCerna2079 added the assign-for-review label Aug 3, 2026

github-project-automation Bot moved this to Todo in Data API builder Aug 3, 2026

RubenCerna2079 added this to the August 2026 milestone Aug 3, 2026

Copilot started reviewing on behalf of RubenCerna2079 August 3, 2026 19:10 View session

github-actions Bot assigned Aniruddh Munde (Aniruddh25) Aug 3, 2026

github-actions Bot removed the assign-for-review label Aug 3, 2026

RubenCerna2079 unassigned RubenCerna2079 and Copilot Aug 3, 2026

RubenCerna2079 added the assign-for-review label Aug 3, 2026

github-actions Bot assigned aaronburtle Aug 3, 2026

github-actions Bot removed the assign-for-review label Aug 3, 2026

Copilot AI reviewed Aug 3, 2026

View reviewed changes

RubenCerna2079 and others added 3 commits August 3, 2026 14:10

Fix tests

b270de9

Merge remote-tracking branch 'refs/remotes/origin/copilot/fix-duplica…

3dd7c0e

…te-graphql-operations' into copilot/fix-duplicate-graphql-operations

Merge branch 'main' into copilot/fix-duplicate-graphql-operations

9c16988

Fix failing tests

1557e34

aaronburtle reviewed Aug 6, 2026

View reviewed changes

aaronburtle approved these changes Aug 6, 2026

View reviewed changes

Aniruddh Munde (Aniruddh25) approved these changes Aug 7, 2026

View reviewed changes

Merge branch 'main' into copilot/fix-duplicate-graphql-operations

58139ce

Uh oh!

Conversation

Copilot AI commented Jul 14, 2026 • edited by RubenCerna2079 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why make this change?

What is this change?

How was this tested?

Sample Request(s)

Uh oh!

azure-pipelines Bot commented Jul 14, 2026

Uh oh!

RubenCerna2079 commented Jul 22, 2026

Uh oh!

Copilot AI commented Jul 22, 2026

Uh oh!

azure-pipelines Bot commented Aug 3, 2026

Uh oh!

RubenCerna2079 commented Aug 3, 2026

Uh oh!

azure-pipelines Bot commented Aug 3, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

RubenCerna2079 Aug 3, 2026

Choose a reason for hiding this comment

Uh oh!

aaronburtle Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

RubenCerna2079 commented Aug 3, 2026

Uh oh!

azure-pipelines Bot commented Aug 3, 2026

Uh oh!

RubenCerna2079 commented Aug 4, 2026

Uh oh!

azure-pipelines Bot commented Aug 4, 2026

Uh oh!

aaronburtle Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

aaronburtle Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

Aniruddh Munde (Aniruddh25) Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

aaronburtle left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Copilot AI commented Jul 14, 2026 •

edited by RubenCerna2079

Loading