API Breaking due to Change in DO behaviour.

[phaynes]

The Digital Ocean API has changed requiring the use of private cloud network. The gateway returns "" as per below. Unfortunately, this causes the Droplet requests to fail with a parse error.

// Data returned from a Droplet request.
"networks": { "v4": [ { "ip_address": "10.116.0.3", "netmask": "255.255.240.0", "gateway": "<nil>", "type": "private" },

The following modification to droplet.rs allows the deserialization to "work", but more correctly the "" needs to be removed.
``
/// These exist in the networks field of a droplet.
#[derive(Deserialize, Serialize, Debug, Clone)]
pub struct NetworkV4 {
///pub gateway: Ipv4Addr,
pub gateway: String,
pub ip_address: Ipv4Addr,
pub netmask: Ipv4Addr,
/// Note: Since `type` is a keyword in Rust `kind` is used instead.
#[serde(rename = "type")]
pub kind: String
}

[LoganDark]

PR?

[phaynes]

Yes - sorry for the poor request. New problem due to change in DO API. I am not familiar enough with Serdes to suggest a correct fix.

[LoganDark]

Terribly sorry about this, but I'm not exactly sure what this issue is all about. I'm not sure what needs to change

[phaynes]

If you make a call to the API as per below it always fails due to a parse error.
This is because the API has changed and it now returns "<nil>" in the gateway field instead of a valid IP address.
https://github.com/LoganDark/digitalocean/blob/master/src/api/droplet.rs line 135 is the failing line
https://github.com/phaynes/digitalocean/blob/master/src/api/droplet.rs is where I have changed the IP address to simply a String as a workaround to allow the code to not fail.

I believe their should be some way to either a) Jump in front of the parse after the request to clean up the nil, but better some error handling in Serde's to clean this field up with the parse.

Make sense? Below is a curl request you can see the changed response.

``

    let client = DigitalOcean::new(self.auth_key.as_str().to_string()).unwrap();
    let request = Droplet::get(cloud_vm.id);
    let droplet_result  = request.execute(&client);
    if droplet_result.is_ok() {
        // Never gets here due to a parse error.
    }

``

curl -X GET -H "Content-Type: application/json" -H "Authorization: Bearer XXXX DO KEY XXXXX" "https://api.digitalocean.com/v2/droplets/{droplet-id}"

[LoganDark]

Oh, hm. That does look like a curious situation.

I believe an Option<Ipv4Addr> would work better but it would require custom parsing. Not sure how the heck that would be done in Serde. I can't look into this for a while, apologies. You're free to look into it on your own if you like, report any findings here

[phaynes]

No problem - couldn't get to fix it myself in the short term. I will raise a request with Digital Ocean as a secondary pathway. Will lodge progress here.

[phaynes]

Contacting DO support went as I expected it go. I said your API is returning dodgy data can you not. They said, our API is returning Dodgy data - can you handle it.... Full text below:

Hi there,

Thank you for your feedback; we greatly appreciate you taking the time to letting us know what you'd like to see with our service. I encourage you to share your thoughts about this in our feedback forum: https://ideas.digitalocean.com/

We're constantly looking to improve all aspects of our service and welcome any other ideas or feedback you have! By sharing your thoughts there, it helps us to better prioritize working on the features that you feel need more attention.

I have reviewed the payload and it looks like it is returning a nil object for the gateway in only the private IP networking. Because of the way private networking is setup this object would not be returned.

Here is the returned payload showing the networking from an example droplet:

??????"networks":{
"v4":[
{
"ip_address": "10.132.233.218",
"netmask": "255.255.0.0",
"gateway": "",
"type": "private"
},
{
"ip_address": "104.131.175.174",
"netmask": "255.255.240.0",
"gateway": "104.131.160.1",
"type": "public"
}

I believe that it might be best to have the application handle a nil object exception during parsing rather than simply failing.
If you have any other questions please feel free to let us know.
Thank you for being a customer and have a great day!

Erwin E.
DigitalOcean
Developer Support Engineer II

[phaynes]

**Least Recommendation: Change type of NetworkV4.gateway field from an Ipv4Addr to a String. **

1. Digital Ocean have introduced a breaking change to the API making a key feature of the API un-usable. Very sucky.
2. The correct fix would be to adapt the Serde's parsing process to handle the dodgy data. This is complicated, and people don't have time right now for a very minor feature. Sucks.

By changing the type to a String, the API works, except the for gateway field for public networks. More people can continue to use the API allowing to be eventually corrected when time permits. Right now new people won't come on board as the feature does not work at all. The least sucky option.

[phaynes]

Just received the following note back from DO Support. Will test it in the morning and if successful, will be able to
close the issue and withdraw the pull request.

Hello Philip,

Hope you are doing well. Our Engineers worked on this issue and updated the behaviour. Now, when there is no gateway an empty string will be returned instead of . We request you to try it out now and let us know if it works or if you are facing any issues.

We value your feedback in this regard. Looking forward to hearing from you.

Swimmingly,
Srilalitha
Developer Support Engineer II

[phaynes]

Tested the updated API. It is returning an empty string as above, however, the API is returning a "Err(ReqwestError(Error(Json(Error("invalid IP address syntax", line: 1, column: 1024))))) " error

This is the location of the field. I will provide feed back to Digital Ocean.
Did some review of Serde fields and could not ascertain a way to convert the empty string into a valid ip4 address without writing a full on deserializer.

The pull request is still thus needed to have a working version.