Type information for @google-cloud/dns Record/Metadata does not match API documentation nor real data

[mgabeler-lee-6rs]

Please make sure you have searched for information in the following guides.

• Search the issues already opened: https://github.com/GoogleCloudPlatform/google-cloud-node/issues
• Search StackOverflow: http://stackoverflow.com/questions/tagged/google-cloud-platform+node.js
• Check our Troubleshooting guide: https://github.com/googleapis/google-cloud-node/blob/main/docs/troubleshooting.md
• Check our FAQ: https://github.com/googleapis/google-cloud-node/blob/main/docs/faq.md
• Check our libraries HOW-TO: https://github.com/googleapis/gax-nodejs/blob/main/client-libraries.md
• Check out our authentication guide: https://github.com/googleapis/google-auth-library-nodejs
• Check out handwritten samples for many of our APIs: https://github.com/GoogleCloudPlatform/nodejs-docs-samples

A screenshot that you have tested with "Try this API".

This is a problem with declared types, not with running the API

Link to the code that reproduces this issue. A link to a public Github Repository or gist with a minimal reproduction.

This is a problem with declared types, not with running the API

A step-by-step description of how to reproduce the issue, based on the linked reproduction.

1. Call await new DNS(...).zone('...').getRecords()
2. Compare actual responses to the declared types for the returned Records and their metadata: RecordMetadata fields:
   • Record.data is typically an array of strings, not a single non-array object. The fact that it's an array is clear from the constructors in the source that assign it based on rrdatas, which is declared as an array
   • RecordMetadata has an rrdatas field commonly, not a data one as declared. Clearly visible in the underlying API documentation: https://cloud.google.com/dns/docs/reference/rest/v1/resourceRecordSets#ResourceRecordSet
   • rrdatas in the REST API are clearly declared as strings, but this library declares them as {} (object)

As such it's very hard to use at least this part of the library without casting everything to any or otherwise turning off type checking, defeating the point of having types.

A clear and concise description of what the bug is, and what you expected to happen.

The types for objects returned from API calls should match the API

A clear and concise description WHY you expect this behavior, i.e., was it a recent change, there is documentation that points to this behavior, etc. **

That's the whole point of having types, to tell you what fields exist and what types of values they are supposed to contain