-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
app-sync-alpha: 2.55.0-alpha.0 >= cannot migrate to new createResolver without downtime #24108
Comments
The PR changed the scope in which the Resolver is created, so without overrides you won't be able to work around this. With an override, you could try the following:
This is an alpha module, so that means breaking changes may occur from time to time. I hope this helps you work around this breaking change we made! |
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
Thanks for the quick response! We can use your suggestion and create new resolvers to move over to (with different field names), so not the end of the world! |
Oh, I was bitten by this issue. We have a production application and deleting and recreating the resolvers is not a good option for us. Overriding logical IDs is not practical because our construct that wraps around the resolver creation logic is being used across a number of CDK projects, and we cannot hardcode each project's each resolver's logical ID in the sharable construct. Damn... This is not good. In the CDK v2 migration guide it explicitly mentioned that logical ID change is not expected. Is there not-alpha version of this AppSync module for CDK v2? |
This isn't related to v1 -> v2 migration, it just has to deal with the alpha module making a breaking change while it was still in alpha Appsync has since graduated as of |
|
This is exactly related to v1 to v2 migration. Even when using
The suffix has changed from I see that the resource paths in the metadata have change:
Basically, the v2 resource path does not separate resources with a forward slash, instead it somehow merged two resources paths into one which perhaps is causing the logical ID change. I've tried to fix that by manually adding a forward slash into the new resolver ID (in v1 the resolver did not require an ID), but it did not help since it converted the slash into two dashes
Is there a way I can make the resource path return to its previous shape? |
As mentioned above, this was a change made to our alpha module, where breaking changes are to be expected from time to time. You might be experiencing this in a migration from v1 to v2, but the root cause would be unrelated to the difference between major versions. You can see the PR here #23322 that is responsible for these changes. The Logical ID is changing because the scope in which these resources are declared changed. I don't believe there's any sort of workaround that doesn't involve either staying at |
Got it! Good suggestions. Let me think through them and see what I should do to reduce the risks. Thank you. |
@kadishmal do you have any updates on this? what were your conclusions? I'm currently dealing with the same thing. |
Facing the same issue when upgrading from cdk v1 to v2 |
@PGuimarais The solution represented here: #13269 (comment) worked for me as a work-around:
This does not create new resolvers and you can upgrade without any downtime. |
the above workaround still creates new resources for me
|
Describe the bug
Now that createResolver requires a resource ID, when building the resolver resource we get the "Only one resolver is allowed per field." error as the logical ID is different and it tries to create the "new" resolver before deleting the old one. This is even the case when using the same typeName:fieldName formatting.
Is it possible to use the new createResolver method without having downtime?
Hope this has a simple solution! But if not, would appreciate some guidance on how to move over.
Thanks for the time!
Joe
Expected Behavior
When using the new createResolver which now takes in the ID parameter:
to
It shouldn't create a new resolver when keeping the id parameter the same as the current logical id.
Current Behavior
Throws "Only one resolver is allowed per field." exception when trying to move over to new createResolver method
Reproduction Steps
Shown in expected behavior
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.59
Framework Version
No response
Node.js Version
14.15.4
OS
macOS 13.2
Language
Typescript
Language Version
4.7.4
Other information
No response
The text was updated successfully, but these errors were encountered: