App is sending requests to codepush/report_status/deploy and getting 400 error

[flp]

In our mobile APM tool we are seeing a large volume of requests to https://codepush.appcenter.ms/v0.1/public/codepush/report_status/deploy and 99+% are getting HTTP 400

We initialize our app with options: { checkFrequency: codePush.CheckFrequency.MANUAL } and we call sync with options:

{
  installMode: codePush.InstallMode.IMMEDIATE,
  deploymentKey: '<omitted>'
}

This does not appear to effect the sync call. codePush.sync resolves and successfully downloads new updates.

Environment

• react-native-code-push version: 6.0.0
• react-native version: 0.60.6
• iOS/Android/Windows version: multiple, including iOS 13 and Android 10
• Does this reproduce on a debug build or release build? release, debug not tested
• Does this reproduce on a simulator, or only on a physical device? physical, simulator not tested

[flp]

This may be related, the npm module code-push, which is a dependency, has a file code-push/script/acquisition-sdk.js which constucts a url for report_status/deploy

[andrejcesen]

We're observing the same issue. POST /v0.1/public/codepush/report_status/deploy call fails with status 400, meanwhile GET /v0.1/public/codepush/update_check call succeeds on both platforms.

Edit: updated with new findings

Environment

• react-native-code-push version: 6.2.1
• react-native version: 0.61.5
• iOS/Android/Windows version: iOS 13 and Android 9 (Pie)
• Does this reproduce on a debug build or release build? debug
• Does this reproduce on a simulator, or only on a physical device? simulator

[andrejcesen]

I think I've found the culprit; even though I override deploymentKey option when calling sync, POST /v0.1/public/codepush/report_status/deploy call still uses the default CodePushDeploymentKey set in Info.plist (for iOS) and strings.xml (for Android).

So the (initial) sync call does not respect overriden deploymentKey option. @alexandergoncharov Could you look into it?

[alexandergoncharov-zz]

Hi @andrejcesen, Thanks for digging into this!

I'm not sure that it should be the reason for the issue since we have the algorithm for remembering deploymentKey that was used for sync method. And the logic for calling deploy request will use that remembered deploymentKey.

Could you please check that your deploy request really was called with other deployment key(not that used for sync method)?

[andrejcesen]

Hey @alexandergoncharov, no problem :)

Let me clarify; when initially calling sync, the following calls happen in sequence:

1. POST /v0.1/public/codepush/report_status/deploy → this call has its body param deployment_key set to value written in Info.plist (for iOS) and strings.xml (for Android) and does not respect deploymentKey option provided by the call to sync function.
2. Immediately after I see another call made: GET /v0.1/public/codepush/update_check → this one does have its query param deployment_key set to deploymentKey option provided by the call to sync function.

[alexandergoncharov-zz]

Hi @andrejcesen , Sorry for this delay.

We implemented a fix for this(thanks @andreidubov) and published a new version with these changes: https://github.com/microsoft/react-native-code-push/releases/tag/v6.4.0

Could you please check it and let me know if your issue is gone or you still see this issue? Please let me know if you have any questions.

[ruslan-bikkinin]

Hi @andrejcesen do you have a chance to look on it?

[Shaddix]

For me it's still reproducible using version 7.0.4.

My scenario is the same, we have the following in strings.xml:

<string name="CodePushDeploymentKey" moduleConfig="true" translatable="false">Key is set in JS</string>

However, when I watch Network calls via Flipper I see the call to codepush.appcenter.ms/v0.1/public/codepush/report_status/deploy at app startup, and the body of the request is:

 app_version: "1.0.1"
 client_unique_id: "9b84fe68d253965b"
 deployment_key: "Key is set in JS"
 previous_deployment_key: "Key is set in JS"

In general, however, update procedure works without issues

[lguardado]

I have the same issue in v8.0.2