botocore/botocore/data/ssm-incidents/2018-05-10 /waiters-2.json = Formatted Differently than other waiters-2.json Files about botocore

[tim-finnigan]

Hi @colinbjohnson thanks for reaching out. The latest EC2 waiter models are in this file. Can you specify the differences you're seeing? Looking at these two files, they seem to follow the same basic structure (apart from the order of keys, and the ssm-incidents file containing a description):

Have you observed any inconsistencies in functionality between the waiters, or can you provide more context on your use case?

Waiters are also now maintained by service teams, so if any bugs or feature requests involving waiters would likely need to get forwarded to the corresponding service team. But minor formatting changes may not get prioritized unless there is some use case in which you are blocked.

[colinbjohnson]

Two things to look at (which a linter might catch <- I just don't know if there are linters available that can catch these things):

1. The acceptor configuration in most waiters files utilize list items that end on one line and start on the next line:

Typical acceptor block:

},
{

as opposed to a single-line format used in botocore/botocore/data/ssm-incidents/2018-05-10 /waiters-2.json:

}, {

2. The number of spaces after a "key" in most waiters files is typically 0 spaces whereas in botocore/botocore/data/ssm-incidents/2018-05-10 /waiters-2.json it is 1 space.

Typical waiters file:

"operation": "GetReplicaSet"

Versus botocore/botocore/data/ssm-incidents/2018-05-10 /waiters-2.json:

"operation" : "GetReplicaSet"

[colinbjohnson]

I completely understand how this wouldn't be a priority but I'd also be open to submitting a (separate) PR that includes JSON linting. My own hope would be that something (admittedly small) like JSON linting would help establish the importance of consistency across a codebase and across AWS teams.

[tim-finnigan]

Thanks for following up and expanding on the issue. I brought this up with the team for discussion and the takeaway was that this would need to be addressed by the service team. The reason is because waiter models are shared across SDKs, and any changes we would make to the models would be overridden by changes made by the service teams.

That being said, I think we should strive for consistency among these models. If you have a support plan then I recommend reaching out through AWS Support requesting that the SSM team update the format of their waiter model. Alternatively, you can create an issue in our cross-SDK repository and someone can reach out on your behalf.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.