-
Notifications
You must be signed in to change notification settings - Fork 231
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
KeysOf<T> and ParentKeysOf<T> create duplicate parameters #462
Comments
@nguerrera I took a look at #506, is my understanding correct that it will help implement this particular PR by not confusing the wrongly-parented key property with a property from the original model type? Will that help with schema naming and inlining? Any other thoughts on what I might need to do to fix this issue? |
I don't think #506 is enough. I've sadly forgotten the details here, but let's look at this together if you have a moment to get on a call. |
I think the real help for this would be #521. I think it might be reasonable to de-prioritize this until we have that. There is an effective (though ugly) workaround to dedupe the definitions that result in the OpenAPI emitter. The customer impact is maybe not high, but we should address the technical debt at some point and I think it would be easiest if we had #521. That said, there might be another fix that doesn't need that and it would still be goodness to fix it sooner in some easier way if we find one. |
Currently, copyResourceKeyParameters creates new properties with different names than the original properties on a new model, but the parent .model still points to the source model. This seems like breaking an invariant and probably needs to be changed, but merely doing so makes the OpenAPI much uglier and more redundant.
This then causes the OpenAPI emitter to generate duplicate parameters and overwrite them. The problem is that there are other circumstances where you can have a duplicate parameter key (for example, with duplicate friendlyNames) where it would be an error to silently overwrite. I'm putting in a workaround to allow the overwriting only if the full JSON representation of the parameter is unchanged, and pointing back to this issue in a comment to find a long term solution.
The text was updated successfully, but these errors were encountered: