Incorrect types for ApplicationVersionStatus for elastic-beanstalk

poph2 commented 11 months ago

Describe the feature

Update the ApplicationVersionStatus's statuses to match what is returned by AWS APIs

Use Case

When Elastic beanstalk application versions are queries using a command such as DescribeApplicationVersionsCommand, the response looks like the below:

{
  "$metadata": {...},
  "ApplicationVersions": [
    {
      "ApplicationVersionArn": "...",
      "ApplicationName": "...",
      "Description": "",
      "VersionLabel": "...",
      "SourceBundle": {
        "S3Bucket": "...",
        "S3Key": "..."
      },
      "DateCreated": "...",
      "DateUpdated": "...",
      "Status": "PROCESSED"
    }
  ]
}

The Status attribute is supposed to be any one ApplicationVersionStatus which are all in Title case while the api responses are in upper case.

In this case, we cannot simply verify the application version's status with the expression appVersion.Status === ApplicationVersionStatus.Processed, this is resolved to PROCESSED === Processed, which was quite frustrating to debug in the context of my project.

Proposed Solution

This should work

export const ApplicationVersionStatus = {
  BUILDING: "BUILDING",
  FAILED: "FAILED",
  PROCESSED: "PROCESSED",
  PROCESSING: "PROCESSING",
  UNPROCESSED: "UNPROCESSED",
} as const;

Other Information

Although the aws-cli documentation described the ApplicationVersion statuses are in title case, this is not the what is returned by the cli. The statuses are in upper case.

The command below provides a response identical to the one returned by the SDK. So we can safely conclude the upper case statuses are to be expected.

aws elasticbeanstalk describe-application-versions --application-name <APP_NAME> --version-label "<APP_VERSION>"

Acknowledgements

[X] I may be able to implement this feature request
[X] This feature might incur a breaking change

SDK version used

@aws-sdk/client-elastic-beanstalk:3.379.1

Environment details (OS name and version, etc.)

Mac OS

RanVaknin commented 11 months ago

Hi @poph2 ,

What you are seeing is a discrepancy between how the service team models their API and how they return data from the server. If you didn't know, all the SDK's clients are code-generated from each service's API model. In this case, Elastic Beanstalk modeled their data with a capital casing: "Processed" as shown in the internal model the SDK uses to generate the client. This can also be seen in the API docs for ElasticBeanstalk:

Status

The processing status of the application version. Reflects the state of the application version during its creation. Many of the values are only applicable if you specified True for the Process parameter of the CreateApplicationVersion action. The following list describes the possible values.

Unprocessed – Application version wasn't pre-processed or validated. Elastic Beanstalk will validate configuration files during deployment of the application version to an environment.

Processing – Elastic Beanstalk is currently processing the application version.

Building – Application version is currently undergoing an AWS CodeBuild build.

Processed – Elastic Beanstalk was successfully pre-processed and validated.

Failed – Either the AWS CodeBuild build failed or configuration files didn't pass validation. This application version isn't usable.

Type: String

Valid Values: Processed | Unprocessed | Failed | Processing | Building

Required: No

But instead, the service returns the data in upper case contrary to what the service team itself modeled.
This needs to be upstreamed to the service team for them to correct their model.

In the meantime, you could "massage" the data before running your comparison, with something like this:

if(appVersion.Status.toUpperCase() === ApplicationVersionStatus.Processed.toUpperCase()) {
  // handle processed status here
}

Please check back for updates. Thanks, Ran~

V975621920

RanVaknin commented 3 months ago

The service team has closed this issue. If you wish to re-engage with them, please open a support ticket via the AWS console and mention the ticket ID V975621920.

Apologies for the inconvenience.

Thanks, Ran~

github-actions[bot] commented 3 months ago

This issue is now closed.

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

aws / aws-sdk