API response changes on #5762 broke many apps

[unarist]

quote from #5762:

As with the notification muting, this will now return an object ({reblogs: [true|false]}) or false for each follow relationship when requesting relationship information for an account. This should cause few issues due to an object being truthy in many languages, but some modifications may need to be made in pickier languages.

Before:

[{
  "id": "1",
  "following": true,
  "followed_by": true,
  "blocking": false,
  "muting": false,
  "requested": false,
  "domain_blocking": false
}]

After:

[{
  "id": "1",
  "following": {
    "reblogs": true
  },
  "followed_by": true,
  "blocking": false,
  "muting": false,
  "requested": false,
  "domain_blocking": false
}]

Then, when I open followee's profile on iOS apps...

• Amaroq crashed
• Pawoo couldn't show any relationsips, and follow/unfollow button disappears
• iMast, Tootle, friends.nico show as "not following"

also my friends says Tusky and SubwayTooter are also broken. I think those breaking change shouldn't be happen on Mastodon 2.1 because it's not a major version up.

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• [-] This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[nightpool]

@Gargron @aschmitz interested to hear your thoughts, but I'm guessing the cleanest way to fix this is to just make it a new property instead: "muting_reblogs" or "following_reblogs"

adding an entire new endpoint version number for something that's really such a simple change and can be done in a backwards compatible way seems excessive.

[aschmitz]

I don't have a strong preference. I think the new API is the cleaner way of returning the data, given that it's a property of the following or muting setting, but I do see the semver issue (and obviously crashing clients and other unwanted behavior is bad). Threading new properties through the interface may be a bit of a pain if I recall, though. Out of curiosity, has the notification muting change (which uses the same API response style) made it into a numbered release yet? I'm open to whatever seems most feasible. I suspect we'll have to change (probably in the way @nightpool suggests), rather than getting all the apps that might break to update and flaunting the semver rules, but if someone else has ideas, I'm open to them too.

[Gargron]

Hm, okay, maybe I made the wrong call... But neither of the API changes is in a release yet, are they? If I remember correctly, the optional notification muting PR did not make it in time for 2.0.0. If everyone agrees, I will restore the old response format on the v1 methods and create equivalent v2 methods.

@unarist @aschmitz @nightpool

adding an entire new endpoint version number for something that's really such a simple change and can be done in a backwards compatible way seems excessive.

Well, I thought it'd be backwards-compatible because of "truthiness" in JavaScript and Ruby, but to be fair any typed language like Java will throw its hands up into the air at a slight structure change. I think if we just see the v1/v2 in the API URL as versioning of the individual end-points and not versioning of the entire API, nor as something connected to the software version, then it's fine to do this.

[aschmitz]

Yeah, that's fine, though it doesn't quite feel like it warrants a whole new version. What would you think about having the serializer just pull those properties out and make them separate booleans like @nightpool described?

[nightpool]

yeah making it a v2 endpoint feels really premature—it's a pretty small compromise for no real reason. (also it'd affect a bunch of endpoints I think?)