Unexpected change to API response for sprint / sprint field in Jira Software Cloud

Jira Development Jira Cloud
, , ,
1

Afternoon,

We got caught by surprise today and had to drop what we were working on to ship fixes to two of our products - Easy Agile User Story Maps and Easy Agile Programs.

At around 330pm we had a support request detailing an issue with Easy Agile User Story Maps where it was failing to display issues associated to a sprint in the appropriate sprint swimlanes. The issues were appearing in the backlog instead.

A bit of investigation and we knew;

  • No deployments in the past 5 days, so our app was the same
  • The problem was visible for customers, and on our test and production instances
  • We discovered the problem was also present in Easy Agile Programs

Historically the API response from Jira Software included a serialised Java object such as
com.atlassian.greenhopper.service.sprint.Sprint@bc72e06[id=10,rapidViewId=1,state=ACTIVE,name=SampleSprint2,startDate=2016-11-15T09:30:20.410+10:00,endDate=2016-11-29T09:50:20.410+10:00,completeDate=,sequence=1]

We used a regex to parse out the information we needed.

However, we now see a JSON response:
{“0”:{“id”:12,“name”:“Sprint 2",“state”:“future”,“boardId”:1,“goal”:“”}}

Finally, it appears that the API response for all versions of the Jira Cloud API have changed, not just latest / version 3.

The improvement is welcome, however the inconvenience caused by not having a heads up about this in advance is frustrating.

We were lucky to be able to respond before our European customers came online. If we’d missed this before heading home our European and US customers would have lost a whole day.

Kudos to the Easy Agile team for jumping on this and being quick to respond.

In future it would be great to:

  • know about changes such as this in advance so we are not caught by surprise,
  • have the API versions respected so changes don’t propagate to all versions of the API, and
  • have the ability to quickly check what has gone to production (as this wasn’t present in the release notes)

Looking forward to improving this process and collaborating more effectively with Atlassian on future Cloud deployments.

Regards,
Nick Muldoon, Easy Agile

12 Likes
2

Thanks to @mpaisley and her sleuthing it appears the change was related to this deprecation: Deprecation notice - toString representation of sprints in Get issue response

We missed that in 2017 and it caught us today.

Thanks to the Atlassian team for their prompt response and investigation!

3 Likes
3

It is not the first time this year when Atlassian breaks API without clear or prior notice :frowning:
API is not a contract that we can rely on anymore, unfortunately.

On the other hand, we’ve been contacted recently regarding a change in /mypermissions endpoint. It was a reminder about the deprecation that we missed. Atlassian team took the trouble and checked the usage of the endpoint to notify interested parties.

All in all, it all depends on the people and the team handling the change.

4

Got hit with this as well and it pretty much cleared off our deployment plans for the week. Thank you Atlassian.

I’m sorry but issuing a deprecation notice back in 2017 and 2 years later acting on it - it doesn’t work. So Atlassian’s expectation is that we review the historical deprecation notice list each time we make an api call - because you know - they might have decided 2 years ago to change something at some point in the future.

Atlassian’s communication is seriously lacking and while I thought that they were taking the problem seriously - it doesn’t seem like it. I shouldn’t have to be this aggressively protecting my code against an upstream system. I could as well just be scraping Jira’s html - I would probably have as much reliability.

If any Atlassian wants to talk to anyone in the ecosystem and have a 2-way conversation about what we’re seeing and experiencing - please reach out - there are a lot of us out that are more than willing to talk to you because this is starting to get really frustrating.

5

Got hit by this as well!!

6

As I’m trying to get my app working again so I can get back on track. The deprecation notice is out of date. It says we should be getting this back:

"customfield_10021": {
    "1": [
        "com.atlassian.greenhopper.service.sprint.Sprint@1bf75fd[id=1,rapidViewId=1,state=CLOSED,
name=Sprint 1,startDate=2016-06-06T21:30:53.537+10:00,endDate=2016-06-20T21:30:00.000+10:00,
completeDate=2016-06-06T21:30:57.523+10:00,sequence=1]",
        "com.atlassian.greenhopper.service.sprint.Sprint@1689feb[id=2,rapidViewId=1,state=FUTURE,
name=Sprint 2,startDate=<null>,endDate=<null>,completeDate=<null>,sequence=2]"
    ],
    "2": [
        {
            "id": 1,
            "name": "Sprint 1",
            "state": "closed",
            "boardId": 1
        },
        {
            "id": 2,
            "name": "Sprint 2",
            "state": "future",
            "boardId": 1
        }
    ]
}

But I’m getting back:

[  
   {  
      "id":1,
      "name":"SAM Sprint 1",
      "state":"active",
      "boardId":1,
      "goal":"",
      "startDate":"2019-11-06T14:18:11.557Z",
      "endDate":"2019-11-20T14:18:00.000Z"
   }
]

My guess is that since the deprecation is related only to the getIssue - that’s the only thing that was tested/verified (I’m going to be nice and assume that that’s still done)?

Update: Found one of my test instances returning things as described in the deprecation note. My guess it’s in the feature flag list perhaps? Either way - still would be nice to find out what we’re supposed to be expecting and what’s going on. :slight_smile:

1 Like
7

We’re also heavily affected by this issue!

8

We’ll reach out to the prod/eng team to have them chime in on this.

2 Likes
9

FYI, we adapted the apps to support both response bodies so that we are backwards compatible on Server and DC.

10

Update: The change has been rolled back as of Nov 20, 12:29 PST (or use the timestamp of this post). More details comms about this incident/change and go-forward plan will be shared later.

11

So indeed, this was a change that was announced back in April of 2017… and it landed in production some time yesterday. Clearly, this caught many vendors by surprise, and was not an ideal situation for everyone involved, including our customers. We sincerely apologize for the inconvenience this may have caused, and we’ll continue to strive to do better.

More formal comms/announcement about the go-forward plan are to come.

3 Likes
12

Thanks @nmansilla. I’m sure I speak for all vendors when I say that we all appreciate yours and your entire teams advocacy for us.

I will restate though( and I’m pretty certain that there’s a slew of vendors willing to do the same):

1 Like
13

Still good to see that someone is finally cleaning up all those stale feature branches in the repo :joy:

1 Like
14

Actually, the notice stated that the change was effective starting 1 April 2017. We don’t know when the notice was actually published.

April 1? Maybe it was an Easter egg? :wink:

In any case, we (our customers) got affected by the sudden change too.

1 Like
15

Thanks for performing a rollback @nmansilla :slight_smile: We were affected as well and now I’m wondering what to do as @danielwester pointed out the response structure doesn’t look like the one that has been announced before. Will there be an update to the announcement or how can we mitigate this problem before it will be deployed again?

16

Hi Everyone,

Thanks for your patience in relation to this issue.

As Neil announced, we have temporarily rolled the change back as it caught many of you by surprise. I’ll be catching up with the team involved in the next few days to discuss when they will be putting this change back in place in production, what our learnings were so we can avoid a scenario like this in future and in relation to publishing a new and updated deprecation notice giving appropriate warning.

Once the deprecation notice is published, you will be welcome to ask any specific questions about the change so we can ensure you’ll have things working before it takes effect.

Cheers!
Melissa

2 Likes
17

Has the change been reverted??

18

Yes, it has, across all instances. The API is returning the toString format of sprint info the custom field again.

19

Hi Melissa,
thanks for rolling this back so quickly.
One suggestion for the future: figure out a way for vendors to implement support for the change before it’s rolled out. Either through a feature switch we can ask to enable on test instances, or through a fake Sprint field that has the new “schema” and returns the new data format. Otherwise, we’ll never be certain our implementation is correct.

Thanks,
David

2 Likes
20

I know I’m in the minority here. But I was just beginning to develop against the API yesterday and was happy to see the JSON response. Then, today, as I was testing my development started failing. It took me a few searches to find this thread and discover the rollback.

Given that the JSON appears to be the future, is there somewhere I can go to subscribe and be notified when you’re ready to roll it out again?

I would also suggest that this would be the kind of thing you could do in a newer version of the api without breaking the older ones. Either that or, as mentioned in another comment, some sort of feature toggle would be great. I would much rather have the JSON response if there’s even an experimental way to get it?

1 Like