Proguard Upload: Manually-specified UUID not respected

[szokeasaurusrex]

A customer has reported that when using the --uuid flag to the upload-proguard command, the ProGuard mapping appears to be assigned a different UUID from the one they specified.

See details on attached Linear issue (Sentry employees only)

[linear]

CLI-296

[szokeasaurusrex]

After further investigation, we determined that this problem occurs when a ProGuard mapping, which has been uploaded previously, is uploaded again with a different UUID than when it was originally uploaded.

This behavior could occur because different UUIDs were passed to --uuid on each upload, or because one of the uploads had a manually-specified UUID, while another upload used the default. Since Sentry CLI computes the default UUIDs deterministically based on the ProGuard mapping's contents, this bug cannot affect users who never set --uuid manually.

We will treat this issue as a documentation issue. We will document that users who use --uuid need to consistently use --uuid and compute the provided UUID deterministically based on the ProGuard mapping's contents; otherwise, they will not get the UUID they expect in Sentry.

As a follow-up, we'll introduce functionality to compute the UUID that the Sentry CLI would set for a given ProGuard mapping. That way, users who need to know the UUID prior to upload can get this, without needing to manually specify the --uuid flag. If we do this, we can probably even deprecate --uuid and recommend folks to switch over to just using the CLI's default UUID

[StefMa]

Hi @szokeasaurusrex ,

unfortunately I don't see what the original customer reports, but it seems we also have some kind of issue with that (another customer 🤓 ).
To me, this doesn't seems to be an documentation issue, instead of an issue with the sentry server(?).
Let me explain:

We are doing white-labels apps (Android).
Every second week we publish ~60 apps, more or less the same code.
Since three years, we are doing the same on every release:

• Downloading the CLI
• Generate a random UUID
• Put the random UUID to the AndroidManifest.xml
• Upload the mapping-file together with the random UUID to sentry

We abstracted away this stuff in our own gradle plugin.
See https://github.com/ioki-mobility/SentryProguardGradlePlugin/
While implementing, we basically followed this documentation: https://docs.sentry.io/cli/dif/#proguard-mapping-upload

Anyways. Recentely we observe crashes are not de-obfuscated anymore.
Some of them give a nice hint:

And indeed, this file doesn't exist!
Checking our release pipeline reveals the problem:

The build is green, but the CLI (or server? 🤷 ) reports "Nothing to upload".

I don't get that! That doesn't make sense. This mapping file was not uploaded before!!
Or does it? 🤔

Now let me exlpain why I think its an issue:
The uuid option should basically tell "Upload the file and assign this UUID to it", correct?
However, it seems that the cli (or server?), calculates the UUID of the uploaded file anyways. Kind of ignoring the override of the uuid.
Since we publishing a lot of apps at the "same time," it could happen, that the "same mapping file" is already generated by another app and uploaded. So when uploading "the same mapping file" but from another app (another build!!) the server "rejecting" the mapping file.
The problem is that

1. The build doesn't break in this case (probably our problem)
2. The AndroidManifest.xml still includes the random UUID ❗

The app carries a UUID and the sentry (android) sdk will send it (when a crash happen), while the sentry sever doesn't have any mappings files for that UUID. (Remember? Because it rejected it 😉 )

What I think should be fixed:
The sentry (server?) shouldn't tell "File already uploaded" in case the uuid is send along. Because this is kind of a "completely new mapping file" (even if its not).
Another option is to give a single mapping file, multiple UUIDs.
This way, you can still calculate the cash for the uploaded mapping file, but assign multiple UUIDs to it. You would store storage, while users can still use random UUIDs.

I hope my explanation make sense 😅
If you have further questions or need more information let me know.

[szokeasaurusrex]

Hey @StefMa — basically what happened is with the upgrade from Sentry CLI 2.x to 3.x, we changed the internal mechanism for uploading ProGuard files to a chunked upload mechanism which is more reliable for uploading large files, and which also supports deduplicating files when it detects that a certain file has already been uploaded (based on the file's hash).

In this case, the UUID is part of the metadata associated with the ProGuard mapping, and not a part of the file contents. Therefore, if you upload the same multiple times, but with different UUIDs, what will happen is that from the second upload, the deduplication logic will see that the file was already uploaded, but this logic unfortunately does not check to see that the UUID metadata has changed, and so we just skip the upload.

The reason we initially decided to consider this issue a documentation issue is because it can easily be fixed on the user end by ensuring that the UUIDs assigned to ProGuard mappings are deterministically computed based on the mapping contents. We already do this in the CLI, when --uuid is omitted, and we just recently released a sentry-cli proguard uuid command which you can use to obtain that deterministically-computed UUID and inject it into your AndroidManifest.xml. By using sentry-cli proguard uuid, you avoid the need to compute a random UUID and pass it using --uuid altogether, and you get the benefit that you can also clearly see when multiple apps have identical ProGuard mappings, since their UUIDs will also be identical.

Still, it is indeed a breakage, and also not a very obvious breakage, either. So, we might reconsider and see if we can implement something in the backend to fix this behavior.

In any case, we would still recommend using sentry-cli proguard uuid instead of manually computing UUIDs and using --uuid, which we have now soft-deprecated. If you use --uuid, you should ensure that the UUID you pass is computed deterministically, so that identical mappings always get the same UUID. Doing so should fix your problem, in any case! 👍