Skip to content

Race condition for setupBrowserFakes vs. first lookup of service #413

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
simonihmig opened this issue Sep 4, 2024 · 5 comments · Fixed by #425 or #432
Closed

Race condition for setupBrowserFakes vs. first lookup of service #413

simonihmig opened this issue Sep 4, 2024 · 5 comments · Fixed by #425 or #432
Labels
bug Something isn't working

Comments

@simonihmig
Copy link
Contributor

This addon has a flaw that I don't know how to best fix (without major changes). The problem is that opting into the mocked behavior is done by calling setupBrowserFakes() in tests, which will register the service (e.g. service:browser/window) with a mockable Proxy class here. However, owner.register() will only work when that service hasn't been used before. So that opens up the possibility to run into race conditions when service:browser/window has been looked up (e.g. by having an @service('browser/window') field be evaluated during app boot) before setupBrowserFakes() was called.

In that case, setupBrowserFakes(hooks, { window: { location: { href: 'https://example.com' } } }) would have no effect. The service would be the one directly proxying to the actual window global, not the Proxy from ember-window-mock. As such this.owner.lookup('service:browser/window').location.href would not be 'https://example.com' (but http://localhost:4200/tests or similar), and this.owner.lookup('service:browser/window').location.href = 'https://example.com'; would actually do a real redirect.

@simonihmig simonihmig added the bug Something isn't working label Sep 4, 2024
@NullVoxPopuli
Copy link
Contributor

🤔 what causes the app to boot and how is it happening before setupBrowserFakes?

@simonihmig
Copy link
Contributor Author

One instance where this came up was rooted in an initializer running (apparently so before setupBrowserFakes), that would lookup a service, that has a connection (via @service) to the window service.

@NullVoxPopuli
Copy link
Contributor

NullVoxPopuli commented Sep 4, 2024

ah, yeah -- initializers have proven to often be problematic -- because while it was browser-services hit this time, it more often affects ones own codebase / services -- or maybe a different addon's services (ember-intl's service is a common one also hit by this initializer behavior).

If possible, I think folks should move all their initializer logic to the application route and init there -- which also gets you async.

@simonihmig
Copy link
Contributor Author

I do wonder though why we need that timing-sensitive register behaviour. After all, ember-window-mock allows you to opt into mocked/proxy mode at any time. Can't the service just use that directly, like all the time?

@NullVoxPopuli
Copy link
Contributor

Can't the service just use that directly, like all the time?

yeah, I don't see a reason why it wouldn't be able to.
Perhaps the original thinking was to "be as light as possible". Maybe it went too far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants