-
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
Change Interface of Return Value From HostedZone.fromHostedZoneId() #6232
Comments
The [Resource].from[Resource]Id() methods would usually just create a mock object with the resource ID populated so that you could pass it around as a "proper" resource. This had the benefit of not needing to do an SDK call to fetch the remaining values from the cloud. I believe the team is moving towards the fromAttributes() methods for looking up resources. |
The object returned from The There might be a work around to look up the SOA record if you import the zone, but it seems to me that the If you want to see an example of what I am talking about check out this point in time from the repo for the construct I am working on. To hit the error, just:
|
@spencerbeggs - I'm trying to see what we changed in Are you certain it was working with |
@shivlaks This breaking change was noted in the release notes from 1.19.0, but looking through the PR, it looks like that code was already in there. I setup a demo repo and went back as far as 1.5.0 and this error is thrown when accessing the property even then. So, perhaps the release notes were just confused. But let me pitch one more time, it would be quite handy to have the sdk make an api call to lookup the zoneName (and also hostedZoneNameServers). I read in another thread that the fromClassId methods being implemented for the most part just create dumb objects to pass around until their values are filled in later, but like looking up a VPC by ID elsewhere in the library, it seems really worthwhile to actually make the api call to retrieve this info during synthesis as other parts of your stack may need to be responsive to them. It is quite common to separate high level components like VPCs and HostedZone into separate stacks. Failing that, perhaps we could change the return interface as throwing an error is definitely confusing when you look at the IHostedZone interface definition and tooling can't warn you about it. Thank you for taking the time to look into this. CDK is a really neat tool that has let me build some cool stuff these past couple months. |
@spencerbeggs I think that makes sense as a feature request. do you. mind updating the issue with the use case and proposed solution? I'm going to drop the bug label from this one and I think we can repurpose it to track the effort. It'll help us prioritize the issue! |
This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
Since release 1.19.0, the object returned from
HostedZone.fromHostedZoneId()
no longer returns the zoneName property, but the function specifies that it will return an IHostedZone, which specifies the zoneName property as required. This is confusing in when using this function as you expect that property as being defined and it takes a bit of spelunking to figure out what is going on.Is there a particular reason zoneName was removed in the first place? It seems there is no way to look up the zoneName property from a HosedZone id now.
Reproduction Steps
Error Log
This is expect from the code, but not from the interface.
HostedZone.fromHostedZoneId doesn't support "zoneName"
Environment
Other
I propose we specify a valid interface to be returned from this method.
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: