twilio-csharp: Breaking change introduced on Twilio.Rest.Lookups.V1.PhoneNumberResource.Carrier property

Issue Summary

Even if it’s indicated on https://github.com/twilio/twilio-csharp/blob/a489e3d7c0110e6c130401b1bca9bced45c739fa/CHANGES.md#2020-12-02-version-5510

Lookups

Changed caller_name and carrier properties type to object (breaking change)

We don’t have any description or details of the object compared to the Dictionary<string, string> before. The Twilio.Rest.Lookups.V1.PhoneNumberResource.Carrier property is unusable as of now as our test account cannot get the details.

Steps to Reproduce

Use Twilio.Rest.Lookups.V1.PhoneNumberResource.Carrier as a Dictionary<string, string> as in 5.50.0 (to get the carrier name for example).
Update nuget to 5.51.0
Observe compilation fails

Code Snippet

var phoneNumberResource = await PhoneNumberResource.FetchAsync(lookupRequest);
var carrierName = phoneNumberResource.Carrier.TryGetValue("name", out var name) ? name : null; // working as of 5.50.0, failing as of 5.51.0

Exception/Log

Could not compile code as `Twilio.Rest.Lookups.V1.PhoneNumberResource.Carrier` property used to be `Dictionary<string, string>` as of 5.50.0 and `object` as of 5.51.0

Technical details:

twilio-csharp version: 5.51.0
csharp version: 8.0

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 10
Comments: 20 (3 by maintainers)

Most upvoted comments

Hello @waellus,

Thank you for reporting this issue!

In order to resolve this issue, we will need to update the documentation. The solution will likely be similar to what @joshsacks provided (thank you for posting the workaround!) since we now return a generic object.

This issue has been added to our internal backlog to be prioritized. Pull requests and +1s on the issue summary will help it move up the backlog.

With best regards,

Elmer

thinkingserious on Jan 19, 2021

@thinkingserious: The workaround is not ideal. Looking at the change in the Java library, it’s clear this is an issue with the Librarian code generator (the change makes even less sense in Java than it does in C#).

Is there any change you can fix Librarian to change this back to how it was? (i.e. a string dictionary)

joshsacks on Jan 19, 2021

I agree with @joshsacks, this definitely feels more like a Librarian bug/regression than a documentation update required. Returning object is strictly worse than returning a meaningful type.

srajkovic on Jan 19, 2021

Still waiting @thinkingserious. This is the code we are using to get around the issue.

var carrierDict = JsonSerializer.Deserialize<Dictionary<string, string>>(phoneNumberResource.Carrier.ToString() ?? string.Empty);
var carrierName = carrierDict != null && carrierDict.TryGetValue("type", out var name) ? name : null;```

DavidEggen on Dec 22, 2021

@thinkingserious Can we get a technical answer as to why this change was made? You’re generating a lot of the code, I understand that. But the generator was working correctly before. Why does it not work now? Maybe you guys switched generators?

TylerDM on Jan 20, 2021