Cloud app does not receive (Jira) migration events

I’m having a similar problem to what Nhan reported a few days ago: I’m trying to work on migration support for our application, and can’t get it to receive migration events from the server.

My setup:

  • Jira 8.21.0 with Jira Cloud Migration Assistant 1.6.6 running locally, with dev mode enabled
  • Jira Cloud with dev mode and private listings enabled
  • we have a private dev version of our app, with a special app key, installed on the server and the cloud Jira (neither of these went through the marketplace, we want to keep things private)
  • used the steps from Use the Jira Cloud Migration Assistant to migrate to trigger migrations

The migrations start, it shows a “Migration complete” message for the Jira data, but then the “App data migration in progress” message remains forever with a spinner beside it.

I see in logs that the server app’s listener’s onStartAppMigration is called and it generates data properly, but the cloud app does not receive any migration event from Jira, and the “Logs and reports” of the migration says “No errors occurred”.

I tried POST-ing messages by hand to the migration URL and they show up properly in the logs of the receiving app, so I’m pretty sure we’re not just dropping them.

Note that this entire setup worked alright a couple of weeks ago, although I was using different Jira instances at the time, and I think the Migration Assistant was an older version. That time I also had a period where I was getting no calls at all, and it sort of fixed itself overnight without me seemingly doing anything different. Now I can’t get it to work again at all after a whole day of trying.

The app key we’re using is qoti.rfc.test-bb and the instance we’re using to test migrations is qbb.atlassian.net.

Hi @bbutnaru,

If you can share the server key and cloud key, Atlassian Support can help to check the registered migration endpoint.

Hi @bbutnaru ,

Could you double check whether your endpoint is not depending on the field webhookEventType that was removed a couple weeks ago? The timeline matches with your error.
You’ll find more details on the deprecation notice.

Regards, Andre

Hello @AndreRosot , thanks for looking into this.

Yes, I confirm we don’t use that webhookEventType property, we did it the “new” way from the beginning. Also, the server that receives the requests is configured to log anything it receives, even if it doesn’t understand the request. And we don’t get anything at all for migrations.

@NhanNguyen the app key and instance are at the bottom of my initial message. I might have added that in an edit a bit after I posted it. (Both the server and cloud app have the same key.)

Thanks @bbutnaru !

I checked that site and there were different endpoints registered for the cloudAppKey qoti.rfc.test-bb and qoti.rfc.dev.bb.

On our logs, I did find some transfers being done for the app key qoti.rfc.dev.bb but none for the one you pointed out (at least in the last days).

I would suggest double checking the values returned from the method getCloudAppKey on your server migration listener. Here’s a page with more details: Server listener

Please let us know if that helped.

Andre

@AndreRosot Thank you for checking the logs!

I can’t believe I stared at those app keys for most of two days and didn’t notice they were not matching :man_facepalming:

Ok, so I made extra-sure each method returns the correct keys:

2022-01-20 16:19:14,306+0000 ForkJoinPool-4-worker-12 DEBUG admin 979x13394x1 1bzze00 172.18.0.1 /rest/migration/latest/plan [c.q.rf.migrate.AppMigrationListener] getCloudAppKey called
2022-01-20 16:19:14,306+0000 ForkJoinPool-4-worker-12 DEBUG admin 979x13394x1 1bzze00 172.18.0.1 /rest/migration/latest/plan [c.q.rf.migrate.AppMigrationListener] getCloudAppKey returning qoti.rfc.test-bb
2022-01-20 16:19:14,311+0000 ForkJoinPool-4-worker-15 DEBUG admin 979x13394x1 1bzze00 172.18.0.1 /rest/migration/latest/plan [c.q.rf.migrate.AppMigrationListener] getServerAppKey called, returning qoti.rfc.dev.bb

(For the record, qoti.rfc.dev.bb was the key I used last time, for both cloud and server. This time the cloud app key changed, because I’m testing on AWS instead of a local app.)

However, I tried several migrations throughout today and this does not seem to work. I still get no calls on the cloud app. Could you maybe check if getCloudAppKey actually is used? I think I remember reading some other posts that suggested it isn’t actually taken into account.

(The last time the keys were the same on both cloud and server, so that might explain why it still doesn’t work.)

Hi @bbutnaru,

My name is James, and I work with @AndreRosot in the app migrations space. Don’t worry about the server/cloud key mix up. I’ve done similar :man_shrugging: and worse.

I think I remember reading some other posts that suggested it isn’t actually taken into account.

It’s definitely used. In app migration it’s what links the server and cloud apps together, and without it there won’t be a connection made.

Having a look at the logs for the most recent transferId I can see 09c4d6f2-f61a-3021... I can see at 2022-01-21 03:20:29.243 sending the webhook to Jira failed with Failed webhook call: App endpoint did not respond status 504.

But before that, I can see the same stack trace first appearing 2022-01-20 19:53:35.365 (UTC+0) and a total of 6 times.

So, there’s an issue calling into the webhook we have, which is https://test-bb.qoticloud.com/rest/migration.

So, there’s something going on at the receiving end. Can you check?

Regards,
James.

Hello @jrichards,

Sorry about the late answer, I had some other fires to put out at work and the migration part was put on pause for a while. Thank you for your hint about the endpoint errors, that helped me figure out the issue eventually. (We have different logs for different components, and I was assuming that one of them can’t fail, so I was only looking at the logs for the other. Turns out I was wrong…)

Anyway, the good news is that after I got that sorted out, and a dozen other issues besides, I finally got something that looks more-or-less good enough for a first version.

We do have a couple of remaining issues, but I’ll open new threads about them. Thank you again for your assistance!

1 Like