Incorrect asset static renditions status

[masterT]

When using static_renditions and video_quality to create an asset it does not contains static_renditions.status. The gem is inferring the value to "disabled".

{
  "static_renditions": {
      "files": [
          {
              "width": 1280,
              "type": "standard",
              "status": "ready",
              "resolution_tier": "720p",
              "resolution": "highest",
              "name": "highest.mp4",
              "id": "...",
              "height": 720,
              "filesize": 1925067,
              "ext": "mp4",
              "bitrate": 1538816
          }
      ]
  }
}

MuxRuby::AssetStaticRenditions.new.status
=> "disabled"

I would expect it to return nil same when setting it explicitly to nil:

MuxRuby::AssetStaticRenditions.new(status: nil).status
# => nil

[philcluff]

Hey @masterT, thanks for the feedback on this - we weren't able to make the static_renditions.status field fully optional in our API as we need to support SDKs that are in the wild that consider this a mandatory response field.

When you're using the new static renditions API, you'll indeed see static_renditions.status set to disabled, I'll make sure to add this note to the documentation.

Thanks!

[masterT]

This is missleading in the case you save the MuxRuby object as JSON and load it with the MuxRuby object. The JSON won't be the same. The original payload won't include the status.

I think this could lead to problem.

If nil is an allowed value, why not default to it when not provided?

[philcluff]

Hey @masterT, thanks for the feedback, let me have a deeper look at this - nil should not be an allowable value for this field at the API level, but we may not be able to control that in the OpenAPI generator that currently backs this SDK.

[philcluff]

Hey @masterT, OK I see what's happening here - sorry I misinterpreted the initial report as related to the legacy mp4_support field, which has more complex interplay with the legacy MP4 modes where we've had make some harder choices to maintain backward compatibility.

static_renditions.status is indeed intended to be optional at the API, and when you're working with the new static renditions API, this field is omitted due to the new status field on the new status field on each rendition - static_renditions.files[].status

This SDK is generated from our OpenAPI specification, and at the moment, this SDK is generated using an old version of openapi-generator, which has many known limitations. We're expecting to replace this with a more modern SDK in the coming months, like we did with mux-node last year.

We'll take a quick look and try to see if there's an easy fix in the short term by flagging this field as nullable in our OpenAPI specification, but I suspect there will be downstream impact of that change that we're not able to immediately take on. Unfortunately this is likely something you'll need to handle for now.

[philcluff]

Hey @masterT.

This is modelled correctly as an optional field in our OpenAPI specification, which we use to model the API, this is an artefact of how openapi-generator generates this SDK. There's no plans for a short term fix for this at the moment.

As I mentioned before, we're planning to replace this entire SDK in the coming months with a much more modern SDK, and I'll make sure this is on the list of things for us to check in the new SDK.

Thanks.