# Graphql duplicate field definitions caused by conflicting singular/plural naming in fields

**URL:** <https://community.fibery.io/t/graphql-duplicate-field-definitions-caused-by-conflicting-singular-plural-naming-in-fields/9714>\
**Category:** Bugs & Issues\
**Tags:** graphql\
**Created:** [October 1, 2025, 10:36am UTC](https://community.fibery.io/t/graphql-duplicate-field-definitions-caused-by-conflicting-singular-plural-naming-in-fields/9714 "2025-10-01T10:36:19Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Yuri\_BC](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yuri_bc/32/8803_2.png) [@Yuri\_BC](https://community.fibery.io/u/Yuri_BC)\
**Post date:** [October 1, 2025, 10:36am UTC](https://community.fibery.io/t/graphql-duplicate-field-definitions-caused-by-conflicting-singular-plural-naming-in-fields/9714/1 "2025-10-01T10:36:19Z")

</div>

**Issue Description** :

I encountered a GraphQL schema validation error where duplicate field definitions arose from overlapping resolvers in Databases, blocking query execution in automations. This stemmed from conflicting singular/plural naming in fields, causing the generated API to fail validation.

**Example** :

1. Create a “Task” Database with a to-one field named “task” for linking to a parent—this generates a mutation “task”.
2. Add a to-many collection field “tasks” for subtasks—this generates a query “findTasks”.
3. The “tasks” collection clashes with the “task” mutation resolver in the merged schema, resulting in “Field “Mutation.tasks” can only be defined once.”

**Prevention Strategy** : Fibery can prevent this by enforcing uniqueness checks in the UI during field/Database creation to flag potential duplicates before saving.
