@mjkkirschner @QilongTang Curious what you guys think of this approach? I can update the message but specifically displaying the warning as a ToolTip

👍 was thinking about this @alfarok , think we could limit the length of the string in the GitHubCrashReportBody method, to avoid some of the nastiness of Github erroring out with 414 ?
Yes, stack traces might be truncated then, but should always have at least the first few lines.

Otherwise, all up for a GithubApp, just don't know how we'd distribute/include the API key needed ?

Hey @radumg, I gave that a quick attempt right after the issue was discovered and remember running into some other issues. I think the max url length that was guaranteed on all browsers were slightly over 2k chars. I can't remember if this approach didn't work because it diluted the stack trace to almost nothing or I hit another error. I do agree it would be a better solution if possible so I can spend a little more time investigating.

If we eventually used a GitHubApp for all our GitHub automation we could use a public API gateway that calls a lambda function which would have the client id/secret stored as environment variables or something similar. I think it would be cool and could be used for other purposes but I don't think we have the bandwidth to prioritize this at the current moment.

Yep, that's what i imagined as well - hard sell to introduce yet another service to maintain just for this.

@radumg I have been messing around with the the uri length and seem to run into other errors in the redirect regarding security and end up getting a 500 error. It isn't related to escaping characters I don't think either as I am reducing the stack trace before building the uri. Using 2-factor OAuth also uses an additional redirect which may cause issues. 🤔

replaced with #9523