sentry errors for captcha web views and registration attempts

[haileyok]

Why

We should have some more robust error reporting around signups. This adds Sentry logs to the most sensitive areas of that flow:

• Captcha webview errors
• Other cases where a captcha isn't set (we shouldn't hit this one but just in case?)
• Any failure after submitting the registration request

Test Plan

Not really sure how to test this one, aside from waiting for these to come through on Sentry. For what it's worth, we already had some of these coming through but this makes the errors a little easier to set up alerts for using the "Signup Flow Error:" prefix.

[render]

Your Render PR Server URL is https://social-app-pr-3761.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-coo72q7sc6pc73a8tu50.

[github-actions]

Old size	New size	Diff
6.49 MB	6.49 MB	508 B (0.01%)

---

[gaearon]

Maybe not important in this particular case but in general we should get out of the habit of assuming that an error has a particular type. E.g. you technically can throw null or throw undefined or throw 'foo' and it's important that this doesn't trip or break error reporting. So errors are generally unknown maybe.

[haileyok]

Ah, yea here these do have an object value, since they come from nativeEvent. But for consistency sake going forward, sure lets switch to unknown here 👍

[gaearon]

Hmm are passing the event itself? If so, does it turn into something reasonable when we stringify it later?

[haileyok]

The nativeEvent is just an object of various values that comes back from the native code when it fires the event. In this case, nativeEvent has the following values (depending on where the error comes from)

[gaearon]

ok but test the error paths for real errors (e.g. make the iframe trigger onError for real etc)

[haileyok]

iframe error might not be reliable (I think onLoad will actually always fire here https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#error_and_load_event_behavior) so let's track with a few different things:

• User didn't complete the captcha in 20 seconds
• User pressed the back button on the captcha page (likely indicates they encountered some sort of error)

[haileyok]

@gaearon Can you think of any other meaningful ways we could get an error from here, mainly on web? The onHttpError and onError do fire correctly on web, though we can't get errors from the iframe. I think these are pretty good indicators though of errors (over 20s to complete and pressing back), and if we see a spike we can take it as a problem.

Edit: Let's make that 30 seconds instead. 20 seems kind of low honestly.