Server instance cannot receive the message sent by cloud - Feedback API

Hello everybody!

We’re trying to use the Feedback API from JCMA to check if the migration should continue to be processed or not.

We send pre-flight checks to the cloud instance, validating if all the Jira projects were migrated and then, on the cloud side, we send a message to the server by following this documentation.

On the Server side, we’re making a polling request to check if the cloud has sent any message.

In our test environment, we are forcing Cloud to send a Failed signal but nothing happens on Server side, it keeps receiving the following Jira message:

Received an unexpected status code; expected [200], but received 404: {"timestamp":"2021-06-15T14:02:33.138Z","status":404,"error":"Not Found","message":"No message available","path":"/feedback/091a9ffe-b164-375a-8e4f-ed40bc8cc134"}

Any suggestion to get it working?

Thanks in advance,
João Ferreira

Hi @joaocferreira10,

I can see in the logs the transferId so the transfer is happening. As I can see you’re getting a 404 response, what’s the exact URL you’re calling? It should be a POST request something like


with a payload of the content you want your server app to receive, for example


Let me know if this helps.


Hello James.
The problem is not related with the cloud since I send a POST request to that URL and it responds with 200 (success).
Francisco Santos

Hello James,
As Francisco mentioned above, the body is being sent correctly and a response with a status code of 200 is being retrieved.
In our end, Jira Server, we are making polling requests to check when the feedback as any useful response for us to continue(or not) with the migration.
You can see what I’ve explained in these two methods:

private CompletableFuture<Map<String, Object>> pollFeedback() {
        CompletableFuture<Map<String, Object>> completionFuture = new CompletableFuture<>();
        feedbackPoller = executor.scheduleAtFixedRate(
                () -> fetchFeedback(completionFuture),

        completionFuture.whenComplete((result, thrown) -> feedbackPoller.cancel(true));
        return completionFuture;

    private void fetchFeedback(CompletableFuture<Map<String, Object>> completionFuture) {
        Map<String, Object> feedback = gateway.getCloudFeedback(transferId);
        if (containsFeedback(feedback)) {
  "Cloud feedback contains migration feedback");

Before and after Cloud triggers the feedback we always receive the 404 messages that we pasted in the original question.

João Ferreira

Hi Team,

Thanks for the clarifications there. I’ve reviewed our code and tests, and also the logs. I can see for transferId=091a9ffe-b164-375a-8e4f-ed40bc8cc13 there are no feedback messages sent via Connect, which is why you’re getting the HTTP 404 message. From what I can see for that specific transferId there are other interactions like get mappings and containers.

I can see other transferId values attached to the same appKey for the feedback channel.

So, it’s just that specific one that is giving 404 because there’s nothing to pick up. Can you confirm you have sent from the Connect side a feedback message?

You will always get a HTTP 404 before the first feedback message is sent through Connect. We don’t provide an empty response.


Hi James.
I confirm that we send a feedback message from the Connect, here is the code for that:

const httpClient = context.createHttpClient();
    return new Promise((fulfill, reject) => {{
            url: `/rest/atlassian-connect/1/migration/feedback/${transferId}`,
            json: { details: feedback }
        }, (err: any, res: any = {}, data: any) => {
            if (err) {
                Logger.error(`Failed to send feedback to app migration for tenant: ${context.tenant}`, err);
                return reject(err);

            if (res.statusCode === 200) {
      `Feedback to app migration sent successfully for tenant: ${context.tenant}`);
                return fulfill(data);

            const error = new ServiceUnavailableError(`Unexpected error sending feedback to app migration for tenant: ${context.tenant}`, null, { data, statusCode: res.statusCode });
            return reject(error);

Please let me know if we are doing something wrong.

Hi @Francisco.Santos,

Your code looks correct. What I’m saying is that I can see feedback being sent for other transferIds, just not for 091a9ffe-b164-375a-8e4f-ed40bc8cc134. Specifically, I can see feedback being sent for 24 transferIds for your app key in the last 7 days


So, it’s working. But I just can’t see anything for 091a9ffe-b164-375a-8e4f-ed40bc8cc13.


Hello @jrichards,

The transfer Id that we gave you on the original post was one example of many migrations we’ve tried in our test environment.

We understand and validate that those transfer Ids have feedback from the Cloud side, @Francisco.Santos posted that when Cloud sends feedback he gets a status code of 200 proving that he sent the feedback.

However, in all of those migrations, on the Server side, it kept receiving a 404 after Francisco forced the feedback to us.

The problem rellies at that stage when the feedback was sent successfully from Cloud, but when Server asks for it, JCMA returns a 404.

Best regards,
João Ferreira

Hi @joaocferreira10,

Thanks for that. I’ll need to do some testing to see what’s going on. It’s definitely going into the system but I’ll need to run some tests to confirm it’s working on the JCMA side. It will take me a day or two to get a confirmed result.


Hi Team,

I’ve confirmed it’s a bug in JCMA only. I’ve raised a ticket

and will be fixing this in the next day. Sorry for the delay in getting this resolved. Please watch the ticket for updates and I expect the fix to be in the next JCMA release.


Hi @jrichards,
We’re glad that you found the issue.
We are going to watch the ticket and wait for the next release.
Do you have an estimated date for the next release?

Thank you,
João Ferreira

Hi @joaocferreira10,

Officially we don’t announce release dates, but the plan is for the 2nd week of July (part of the regular release cadence) unless there’s a hotfix release before that and I’ll try and get this fix included in that.