Error: Only one resolver is allowed per field

[ChrisWun]

The following GraphQL-Schema leads to the Error "Only one resolver is allowed per field" when pushed to the AWS Cloud.

type TypeA @model {
	id: ID!
	typeB: [TypeB!]! @connection(name: "myCon")
}
type TypeB @model {
	id: ID!
	typeA: TypeA! @connection(name: "myCon")
}

The generated Resolver and CloudFormation looks good to me. The Resolvers seems to be unique per Type and Field.

We had to rename the non-collection property to something else so the resolver could be deployed:

type TypeA @model {
	id: ID!
	typeB: [TypeB!]! @connection(name: "myCon")
}
type TypeB @model {
	id: ID!
	typeBTypeA: TypeA! @connection(name: "myCon")
}

I don't know if this is a CloudFormation or a Amplify CLI Bug. There is a Forum Post (https://forums.aws.amazon.com/thread.jspa?messageID=884492&#884492) which I replied to because this can be that CloudFormation Bug. But since I use the Amplify CLI, I wanted to bring this up, even if it's just for documentation.

[sakhmedbayev]

Same thing here :-(

[FemkeBuijs]

Same thing here.

I tried adding a keyField to a connection (#300 (comment)) and I get the following error:

Cannot update GSI's properties other than Provisioned Throughput. You can create a new GSI with a different name.

So I deleted a table and all it's connections, and then tried to re add it, which gave me the following error:

Only one resolver is allowed per field. (Service: AWSAppSync; Status Code: 400; Error Code: BadRequestException; Request ID: b21a3364-2a37-11e9-bce1-cfaf75c1d372)

The resolver does not seem to be in the AppSync Console anymore, so the only way I see is to delete the stack (as suggested in the forum posted above) which is really not an option for me.

[mikeparisstuff]

It seems there is some path that leaves APIs in a state where a resolver is left dangling even after the field is removed from the schema. When this happens you can get around the issue by going to the AppSync console, adding a field to the schema with the same name as the supposed conflict, delete the resolver record by selecting it from the right half of the schema page and clicking "Delete Resolver" on the resolver page.

I will try to reproduce and identify the underlying issue but it appears that it is not within the Amplify CLI itself.

[wbroek]

Got the same error today, also renamed my connection and got the error Only one resolver is allowed per field.

Only way I could correct it was to remove the two models which had the connection (first made a backup of data in DynamoDB), push it so all was removed and then push the model without connection in it so it recreated the schema, resolvers and table and after that re-made the connection

[ChristopheBougere]

@mikeparisstuff trick worked for me, but really annoying. Hope it will be fixed soon!

[sprucify]

I had the same issues.
Carefully read the log to see which resolver creation fail.
Go to your Appsync panel to schema and on the right side look up the resolver in question and delete it.

Appsync is not always perfectly in sync I guess :P

[pierremarieB]

Same problem here as well, it happened to me when I tried to rename a Resolver. It seems like the renamed resolver is created by CF before the old resolver is removed and therefore raises this exception.

@sprucify solution works but this needs to be fixed as it's not viable in the long run

[kaustavghosh06]

@pierremarieB Was the resolver that you added, a custom resolver?

[pierremarieB]

@kaustavghosh06 It was a regular resolver. Not sure what you mean by custom resolver.

[oliverandersencox]

I have had this problem when I create models with keys defined and connections within them.

If you leave the connections out and first deploy (amplify push), then once thats done, add your connections and it works.

[janhesters]

I faced the problem too. I was trying to overwrite a resolver that got generated by Amplify for a @connection directive. Furthermore, I couldn't fix it using Mike's fix.

Update: Fixed it. I created an entry in CustomResources.json, which is only needed when you create new resolvers, and not for overwriting them.

[ggriffin]

@pierremarieB wrote:

Same problem here as well, it happened to me when I tried to rename a Resolver. It seems like the renamed resolver is created by CF before the old resolver is removed and therefore raises this exception.

We've run into the same on more than one occasion when renaming a resolver. Attempting to deploy both the old and newly named resolvers, by pointing the old resolver to a blackhole field name, also did not work; CF appears to process creations before deletes and updates. Our current CI/CD approach is to deploy a delete and then deploy the creation of the resolver again under the new name.

[lightsofapollo]

Hit this as well :/ Unfortunate that CF cannot process this as an override.

[aprilmintacpineda]

This happened to me on two different scenarios:

When I'm trying to create a many to many relationship

I simple followed the docs.

When I updated the schema.graphql.

• I needed to add a new column on a table, the column is required.
• The table is already populated with test data that a script I wrote inserted.
• I commented out the schema.graphql and did amplify push which I expected should have removed the data sources and the resolvers.
• I added the new column to the table and did amplify push, at this point I was expecting the API to not contain anything, basically it should have started from "nothing".

The weird part is that when I went to the AppSync dashboard > schema and looked for the resolver, the resolver doesn't exist there.

[BabyDino]

I ran into this issue yesterday. After 2 hours I just gave up and deleted the API, I couldn't resolve the issue. This was testing only, so not really an issue. For production ready API's i'm a little more concerned.

Since I've tried every trick in this issue without result, can anyone point me to the file(s) which causes the issue? Or do I have to dig into CloudFormation? Thanks.

[affablebloke]

I ran into a similar situation Only one resolver is allowed per field. Maybe this will help other developers out there. It seems like AppSync has a chicken before the egg problem and this should be reported to the AWS AppSync development team.

We had a GraphQL type named ChangeInCondition, which had resolvers wired up. Somehow CloudFormation rolled back a deploy and removed the GraphQL type ChangeInCondition from AppSync, yet kept its resolver data somehow.

So upon the next deploy, it would throw the error Only one resolver is allowed per field, due to the fact that it thought ChangeInCondition had a few resolvers bound and CF was trying to re-create them.

Oddly, I wasn't able to remove the resolvers through the aws appsync CLI since the type didn't exist...

aws appsync delete-resolver --api-id XXXXX --type-name ChangeInCondition --field-name status

An error occurred (NotFoundException) when calling the DeleteResolver operation: Type ChangeInCondition not found

So then I decided to try and create the missing type ChangeInCondition and see if I could then remove the resolver. Yep, that did the trick. Funny how creating the "missing type" worked. I thought it would throw an error at the API level. Here it is in Python using boto3...

def main():
    api_id = 'XXXX'
    client = boto3.client('appsync')

    # most fields removed for brevity
    definition = """
        type ChangeInCondition {
            id: ID!
            status: String!
        }
    """
    client.create_type(apiId=api_id, definition=definition, format='SDL')
    client.delete_resolver(apiId=api_id,
                           typeName='ChangeInCondition',
                           fieldName='status')


if __name__ == "__main__":
    main()

[orcunorcun]

Same issue!

[houmark]

I opted for more brute force approach.
To solve same problem "only one resolver is allowed per field."
amplify remove api
amplify push
amplify add api
amplify push
works 100% of the time. don't forget to copy the schema.

ABSOLUTELY DO NOT DO THIS IF YOU HAVE DATA IN YOUR DYNAMODB DATABASE.

This will delete all tables and remove all data. This can only work if your project is in a very early stage and does not have data already.

[apoorvmote]

ABSOLUTELY DO NOT DO THIS IF YOU HAVE DATA IN YOUR DYNAMODB DATABASE.

This will delete all tables and remove all data. This can only work if your project is in a very early stage and does not have data already.

Yes you are right. I should have mentioned this in my reply. You will lose everything. And I am in early stage so this works for me.

[yonatanganot]

I found a solution for this error without losing the data.

Do the following actions for the affected types:

1. Add generated operations with null value inside @model:
   type Name @model(queries: null, mutations: null, subscriptions: null) {...}
2. amplify push
3. Remove generated operations with null value inside @model:
   type Name @model {...}
4. amplify push

Good luck!

[gitzhouxinyu1]

I also experienced this issue.

[manviny]

I found a solution for this error without losing the data.

Do the following actions for the affected types:

1. Add generated operations with null value inside @model:
   type Name @model(queries: null, mutations: null, subscriptions: null) {...}
2. amplify push
3. Remove generated operations with null value inside @model:
   type Name @model {...}
4. amplify push

Good luck!

Working perfectly.
You save me lot of hours.

[apoorvmote]

I had lot of errors that persisted even after losing the data. Try to either run the app on incognito mode (this can be annoying) or remove all data for localhost from setting from time to time. Especially if you are getting lots of errors.

[Jordan-Eckowitz]

I created a new environment and ran into this issue. I commented out the @searchable transform in all models and it worked. I then uncommented it and re-deployed with @searchable.

[iqaldebaran]

I found a solution for this error without losing the data.

Do the following actions for the affected types:

1. Add generated operations with null value inside @model:
   type Name @model(queries: null, mutations: null, subscriptions: null) {...}
2. amplify push
3. Remove generated operations with null value inside @model:
   type Name @model {...}
4. amplify push

Good luck!

@yonatanganot I tray this solution but the next error appear:

[regenrek]

I found a solution for this error without losing the data.
Do the following actions for the affected types:

1. Add generated operations with null value inside @model:
   type Name @model(queries: null, mutations: null, subscriptions: null) {...}
2. amplify push
3. Remove generated operations with null value inside @model:
   type Name @model {...}
4. amplify push

Good luck!

@yonatanganot I tray this solution but the next error appear:

Yep - I get the same here. Since you removed the operations (queries, mutations) on the model you run into this error.

• Tried also @clodal 's approach but this results in the same resolver is allowed per field error.
• You also run into problems if you have a CustomResolver setup
• Tried also to remove schema models add some test table -> push -> add schema and custom resolver back into the scheme -> push - fail
• The only way which worked me so far is the dump everything approach described here: Error: Only one resolver is allowed per field #682 (comment)
  (which shouldn't really be the current solution at all. Dumping is ok while developing but you waste so much time with this...)

I think this issue will avoid most of the problems here (hopefully): #2384

[yonatanganot]

@iqaldebaran @regenrek
What is your schema structure?

[iqaldebaran]

@iqaldebaran @regenrek
What is your schema structure?

@yonatanganot , my schema is the next...
When I comment the "WfItem" and its connection in "WfNode", the schema works without problems, but when I add the "WfItem", it throws the error.

type TKRProject
@model
@auth(rules: [{ allow: owner }, { allow: groups, groups: ["Admin"] }]) {
id: ID!
projectName: String!
description: String
studyCoordinator: String
facility: String
company: String
plant: String
location: String
lat: Float
lon: Float
createdAt: String
updatedAt: String
whatIf: WhatIf @connection(name: "WhatIfModel")
}

type WhatIf
@model
@auth(rules: [{ allow: owner }, { allow: groups, groups: ["Admin"] }]) {
id: ID!
name: String
project: TKRProject! @connection(name: "WhatIfModel")
nodesWhatIf: [WfNode] @connection(name: "NodesWhatIf")
}
type WfNode
@model
@auth(rules: [{ allow: owner }, { allow: groups, groups: ["Admin"] }]) {
id: ID!
description: String
intention: String
boundary: String
designConditions: String
operatingConditions: String
hazardMaterials: String
drawing: String
comments: String
whatIf: WhatIf! @connection(name: "NodesWhatIf")
itemsWf: [WfItem] @connection(name: "ItemsNode")
}
type WfItem
@model
@auth(rules: [{ allow: owner }, { allow: groups, groups: ["Admin"] }]) {
id: ID!
whatIfQuestion: String
node: WfNode! @connection(name: "ItemsNode")
}

[iqaldebaran]

@yonatanganot @regenrek

My solution for my problem... without delete data... was:

• In the schema.graphql, change the name of the "items" in the connection:
• Change "itemsWF" for "nodeItemsWf" and "node" for "itemWfNode" -> amplify push -> Ok¡ All green¡

Other better solution:
1.- Comment all connections or relationships with "#"
2.- Amplify push api
3.- Uncomment all above commented
4.- Amplify push api

[alextriaca]

Raised this as an issue on the AppSync community too - aws/aws-appsync-community#128

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. Please open a new issue if you are still encountering problems.

[github-actions]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels for those types of questions.