OS:
_Platform:_
sentry-cli react-native appcenter marks release with codepush label, but that changes in codepush when staging is promoted to production. Solution: use packageHash, which remains constant and always reflects the actual code.
Per your instructions here:
https://docs.sentry.io/clients/react-native/codepush/
When we push code+maps to sentry, the sentry-cli react-native appcenter command tags it with a release/version that ends in the codepush version label. Since the app can get these values from codepush at runtime via
update.appVersion + '-codepush:' + update.label
we have a match and we see code for app errors in the sentry web console.
That only works for staging! When we code-push promote to production, the label changes to a new number... not determined from the staging label. The match is broken.
If you used the packageHash instead of the label, both of which are available in the same places, the problem goes away! Unlike the label, the packageHash stays the same when the release is promoted to production! This follows the design of code-push: a code bundle from the local filesystem is released to staging, but only selected in the codepush server-side for production. Sentry should follow this: the uploaded bundle files match the codepush packageHash, and may be used for error code display regardless of staging or production.
I can't fix this on my own (without forking sentry-cli), since sentry-cli react-native appcenter appends the label. There's no way for the app to get the staging label when running a production codepush update.
Have other's found some other solution here? I can't be the only one.
For completeness, here's a way to form the sentry release/version we need, from the command line. It doesn't solve the problem since sentry-cli appends label on its own.
```
code-push deployment history Org/App Staging --format json | node -e "
fs=require('fs');
data = JSON.parse(fs.readFileSync('/dev/stdin'))
last = data[data.length-1]
console.log(last.appVersion+'-'+last.packageHash.slice(0,16))
"
````
Hey, thank you for the detailed report and solution provided 馃憤
We will fix this as soon as possible, I will keep you posted.
Seeing this bug too. For example, the initial CodePush (appcenter) deployment is to Staging as v18. When promoted it's v16 on Production. However sentry-cli tags it with the Staging version
> Uploading source maps for release 1.2.3-codepush:v18
Any work-around to override the CodePush deployment version?
+1
@HazAT Diagnosing bugs is almost impossible with this problem. Is there any progress here? I'm trying to manually upload the sourcemaps but it's proving difficult.
sentry's code-push integration is completely useless without giving a distribution name. It always uploads for Staging.
@HazAT any update on this?
Running into this as well...Always uploads using the Staging code-push deployment.
And I do _not_ use the promotion feature of code-push.
EDIT: I added --deployment Production to force the deployment. Works now.
I am closing all old issues, please if this is still a problem feel free to revive it.
Also, consider moving to our new SDK @sentry/react-native if it still happens there please open a new issue.
Hi! I'm on the new @sentry/react-native but Sentry is still having problems linking sourcemaps with issues. When I upload the sourcemaps they correctly link to the release - thanks to the --deployment flag. Thanks for this! However, distribution for the sourcemap is set as None. I believe this is why issues still say 'Source code not found'. How can I get sentry sourcemaps working :(
Could be related to this issue: https://github.com/getsentry/sentry-react-native/issues/703
Most helpful comment
@HazAT Diagnosing bugs is almost impossible with this problem. Is there any progress here? I'm trying to manually upload the sourcemaps but it's proving difficult.
https://docs.sentry.io/clients/react-native/sourcemaps/