runloop timers in FastBoot

[trek]

We ran into an interesting issue with a combination of OAuth2PasswordGrant, FastBoot, Cookie session store and the runloop:

On app boot and authentication _scheduleAccessTokenRefresh will trigger and set up a timer in FastBoot that appears to continually rescheduled itself.

We additionally ran into a similar issue as fenichelar/ember-simple-auth-token#250 where a very large expires_in value overruns node's 32-bit signed integer max size when attempting to parse the cookie.

(node:15570) TimeoutOverflowWarning: 2591999302267 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.
(node:15570) TimeoutOverflowWarning: 2591999302265 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.
(node:15570) TimeoutOverflowWarning: 2591999302262 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.
(node:15570) TimeoutOverflowWarning: 2591999302259 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.
(node:15570) TimeoutOverflowWarning: 2591999302257 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.

Both are leading us to believe that refreshAccessTokens should never be true (the current default) when run in FastBoot.

Happy to PR if that's the case.

For now, we've set refreshAccessTokens to false.

[marcoow]

Thanks for reporting this! Indeed an access token refresh should never be scheduled in FastBoot - PR would be great!