CrashReporting.Init only works if App ID is all caps

Hey @rpolyano,
You must have had a heck of a time getting things going, and I can only imagine how frustrating this must have been to debug. This comes as a bit of a surprise for me, and I'd really appreciate your help in finding where the bug is.

Interestingly enough we're getting reports with mixed cases, and then normalize them before putting them in the database. Let me take a deep dive with you and see if we can figure this out.

Here are some redacted web requests, one upper case, one lower case:
```

01/Feb/2016:11:36:31 +0000 0110μs "POST /api/projects/338D2E6E-<redacted>/crash_log HTTP/1.1" - "Dalvik/2.1.0 (Linux; U; Android 5.0.2; SHL25 Build/SC261)"

01/Feb/2016:11:36:31 +0000 0130μs "POST /api/projects/5fa1b83f-<redacted>/crash_log HTTP/1.1" - "Dalvik/2.1.0 (Linux; U; Android 5.1.1; SM-N920S Build/LMY47X)"
```

We can follow these projects to the database:

```
# Upcase request
select distinct project_id from crashes where project_id like "338D2E6E%";
-> 338d2e6e-<redacted>

# Downcase request
select distinct project_id from crashes where project_id like "5fa1b83f%";
-> 5fa1b83f-<redacted>
```

It looks like 338D2E6E has about 1000 unique crash reports ( I didn't sum how many times we saw each one )
while 5fa1b83f has around 500

Both appear to be fairly active games as the updated_at is very close to when I ran the query
```
mysql> select max(updated_at) from crashes where project_id like "5fa1b83f%";
| 2016-02-01 11:59:27 |

mysql> select max(updated_at) from crashes where project_id like "338D2E6E%";
| 2016-02-01 11:59:28 |
```

The above seems to show that either case *should* work. There might be one or two edge cases if you started using crash a long time ago and tried this change recently.

If you can tell me more about your project, and how you're seeing this issue I'd be happy to take a look at your particular project. This must be frustrating for you, and I can only hope to show you how much I'd like to fix this.

I'll do a little more testing using the plugin with the most recent version of unity.

Feel free to send an email with any details to me at chrisl@unity3d.com

Thanks,
Chris Lundquist

 

I did a few more tests, and I'm still struggling to pin this down.

With Unity 5.3.0f3 I downloaded the latest crash plugin and made a new project.
I pasted:
CrashReporting.Init("0f1f9ae9-55e9-4cf1-820b-2ca6ce8224b6");

into ThrowMeAnException.cs replacing the other similar line.

At first I hit "Play" in the editor clicked the button once, then unclicked Play to stop.
To my surprised, no exception appeared on https://developer.cloud.unity3d.com/gameperf/orgs/silly-hats-only/projects/crash-test

I remembered that the editor holds onto the crashes and sends them in intervals, so I tried again, hitting play, clicked the button then left it running while I checked the website. Within a few seconds the crash appeared.
This was surprising to me as a user, and definitely caught me off guard. As a user I'd expect it to send the crash report as soon as I hit the button, so stopping it shouldn't matter. As a programmer I see why batching is helpful to save the user's battery life and all that.

I think the behavior *should* be that it sends all known reports when the editor/game gets stopped.

To recap all that: Downcase seems to work on a new project, if you click the button and leave it in "play mode" while you refresh the web page.

( Mine took about 5 seconds to show up, because we do a lot of batching. It will take about the same time to see 1 crash report or 1000 crash reports )

This case seems like the biggest "gotchya" I've found.

I also used the API directly with different cases. See: https://gist.github.com/ChrisLundquist/31b1a9355707f83d4842 for details on the test I ran.
Basically:
* made a new project
* ran the send_report script there with the upid in downcase, sending 10
* ran the script with upid in upcase sending 10
* saw all the crash reports on the website after a second (20)

The last thing I could think of was the legacy project case that isn't downcased in the database. I found one and it seems to be working using an investigation like I did in my first post.

In any case, the batching behavior and stoping the scene tripped me up, and improving that seems worthwhile. I'd love to hear any more testing ideas you might have, or the specifics of your project so I can take a look at it for you.

Chris Lundquist