Lots of "Error: Network"s

[noahtallen]

I'm not sure how to debug this one. Essentially, I'm getting a lot of errors from Radar when trying to use trackOnce. Generally, it works ok. However, it seems that about 40% of the time, I receive an error: network result when trying to receive the current coordinates. Do you think it could be caused by trying to call it again while a call is already in progress?

[russellcullen]

Hey @ntomallen, is this still happening? It's possible you're hitting the Radar rate limits (1 req/s and 60 req/hr) if multiple trackOnce() are called in quick succession. Does this seem likely?

[noahtallen]

Hey, that's actually a really great point, that could certainly be the case. Could you point me towards more detailed documentation about that?

Specifically, is that on a per-user basis?

Our app fires that immediately when the app opens and when the user returns to the primary screen of the app, so during development that would happen a lot. On Jul 30, 2018, 11:39 AM -0700, Russell Cullen notifications@github.com, wrote:

Hey @ntomallen, it's possible you're hitting the Radar rate limits (1 req/s and 60 req/hr) if multiple trackOnce() are called in quick succession. Does this seem likely? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[russellcullen]

Yeah the full list of API rate limits can be found here https://radar.io/documentation/api#upsert-user, User PUT is what the SDK uses.

The rate limit is on a per-users basis (not per-org), so you'll most likely see it a few times in development with your setup.

[noahtallen]

Interesting. Yeah, I could definitely see that causing the issue, then. One reason that it gets called so often is to "trigger" an update of the Radar enter/exit events.

[noahtallen]

I think this could be the error, but reading the documentation closely, I see this:

errorRateLimit: exceeded rate limit of 1 request per second per user or 60 requests per hour per user

Wouldn't we be seeing that error code then, rather than ERROR_NETWORK? Though, looking at the documentation for react-native specifically, it doesn't seem that rate limit is one of the errors here. Would that get bundled into the network error?

[russellcullen]

You are correct, through the SDK (and by extension the ReactNative library), we dont surface individual error codes returned from the API and try to group them into more general errors like ERROR_NETWORK.

Would having specific error codes be useful for your use case? Curious if that's something we should expose in the future.

[noahtallen]

Ok yeah, that makes sense. I do think it would be helpful for debugging. We try not to display super technical errors to the user - in this case, we have a log in the settings menu that we use for debugging production errors that our test users encounter, so seeing a more specific error there would be nice.

Maybe an option could be exposed for more detailed errors and logging if needed? On Aug 2, 2018, 3:23 PM -0400, Russell Cullen notifications@github.com, wrote:

You are correct, through the SDK (and by extension the ReactNative library), we dont surface individual error codes returned from the API and try to group them into more general errors like ERROR_NETWORK. Would having specific error codes be useful for your use case? Curious if that's something we should expose in the future. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[russellcullen]

Awesome, thanks for the feedback! The debugging use case is definitely something we want to support. We're actually working on adding debug/logging options in the future to give devs more insight into when and why things go wrong for this exact reason. It sounds like it would be worth exposing more detailed error codes in something like that

[noahtallen]

Sounds great! I'll close this now :)