I changed this to have an empty name so that the deprecation message generated by LoggingDeprecationHandler does not include the location of the deprecated id field. The value of location is somehow random in the yml test and makes it impossible to match with the warnings directive. Please let me know if there is another preferred solution.

I don't think we should remove location information that would be useful to clients just to help a yml test.
Does the yml test need to care?

A warning message is emitted during the yml test that uses the deprecated id field. If not caught, the yml test fails. But there is not existing way we can catch this because:

1. warnings directive requires exact match
2. The location value is unstable during the test, it could be [invalidate_api_key][-1:8] Deprecated field ... for one run and [invalidate_api_key][1:4] Deprecated field ... for another, and some other value for the yet another.

I didn't look into why the value is unstable. There could be value in fixing it? But I noticed that none of the deprecate warning messages in our tests care about the location values, i.e. they opt out of showing the location. For example, updateBy query passes null for parser name so that no location would be shown. Also GetDataFeeds does the same thing as well. I could not find any existing examples that try to match these locations. So I assumed it is not important.

With above being said, if we do wanna keep the parser name and in turn the location value, we have a few options:

1. Remove the yml test that uses the deprecated id field. We can have an unit test for the deprecation message.
2. Or fix the unstable location value in yaml test. I suspect it is caused by how payload is prepared by the yaml test and the fix could take some time.
3. Or enhance the warnings directive so it can match a regex.

I prefer option 1. What do you think? I doubt I am the first person to have this issue given deprecation messages are such a common thing. So maybe I am missing something obvious, please let me know.

I didn't look into why the value is unstable

I assume it's because we randomise the input. The YML Rest tests will randomly send the body in JSON/YAML/SMILE/etc, and might (I can't remember off hand) also randomise the order.

Option 1 makes sense to me.

Option 1 implemented. Also removed the yml test and doc example of using the deprecated id field, which imo is overall benefiical because it's better to not advertise the deprecated usages.

I don't think we should remove location information that would be useful to clients just to help a yml test.
Does the yml test need to care?