Wrong response code when using makeImageRequest

I understand very well the problem and the work that it can represent, it seems fair to me. I did not expect it to be corrected in a hurry, I have already thought about finding a workaround. The proposed solution seems right to me. If an error occurs during image processing, I think that it sould not be a client error (4xx) but a server error (5xx) or a custom code (like 0xx). If you decide to use 5xx code, I think it is a bad idea to use standard code like 500 that can be already used by the server. I propose you can use non-standard code like 520+ code. I'll let you brainstorm about the most appropriate solution for your product. I am at your disposal to help you or if you need more informations. Please keep me informed of the progress of an hypothetical fix Thank you

[quote userid="123172" url="~/developer/connect-iq/f/q-a/219814/wrong-response-code-when-using-makeimagerequest/1040870"]Is there a chance that this problem will be corrected in a future release ?[/quote] I alone don't get to decide what is a bug and what isn't, but I can report it and see what happens. In my mind, the image processing service should: immediately return a non-200 response code to the calling application. attempt to process the response payload for responses with a 200 response code. if an error occurs during image processing, then a suitable error code could be returned (a 4xx or 5xx code seems reasonable, but 400, 417, 424, 499 or 500 seem fair) never return 404 unless the file is not found. It is likely that if a fix is made, it will need to be made to several pieces of software... the image processing service, Garmin Connect Mobile iOS/Android, device firmware (including the ConnectIQ VM), and the ConnectIQ simulator would all need to be audited and possibly fixed. Something like this will take a while.

Thank you, with your answer, I have a better understanding of how it works. I had ideas for other tests. Until now, when the server return an error, the response was empty or json result. Now, I had make some tests returning a fake image with error status code. It seems that if the server return an image, the response code is 200 in the callback even if the status code of the server response is 4xx or 5xx. The response code of the callback directly depends on the result of the pre-processing and don't care about the response status code. If the body of the response is a valid image response code is 200, if the response is an invalid image, response code is 404 in the simulator (and 0 on my watch) regardless the value of the status code. Is there a chance that this problem will be corrected in a future release ?

Thank you for taking the time to fill in those details. The behavior between devices and the simulator should be the same. When using a device, image responses are pre-processed so that the resulting image can be efficiently loaded and displayed by the target device. This functionality may make it a little more difficult for us to provide the actual response code to the calling app.

This occurs with the ConnectIQ simulator (I just test with forerunner 235, fenix 6S Pro and vivoactiv 4). I can reproduce the error with other status code like 403 or 500. In the HTTP Traffic logs, the response code is OK (I can see 401,403, or 500) but response code in the callback is still 404 As you demand, I also check on my watch (forerunner 235), but this time have an unknown error (response code=0) with these different status code from the server (401,403 or 500)