Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
HttpLink
/BatchHttpLink
: Abort AbortController signal more granularly. #11040HttpLink
/BatchHttpLink
: Abort AbortController signal more granularly. #11040Changes from 5 commits
ae5a3a8
fd3a79b
bf6c2b6
0b36195
3d9fddb
f9f1022
766964b
0723cce
8bb804d
8767527
bf36ad4
13b2ca9
97dbfe2
fcf54d6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 Love this change. Love seeing
any
start to disappear!There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any chance you could add some of these tests for batch http link? Since the batch link doesn't use
HttpLink
under the hood, this should give us confidence that implementation works as expected (plus it provides documentation that the batch link also works this way)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once you're happy with how the tests are written for the HttpLink, I'll recreate them over there :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another reason is that I prefer to inline the setup is that it isolates test state. Because we are asserting on test state that can be written by any test in this
describe
block, it is impossible to run these tests in parallel because any given test could update this state and affect another. If we can move this state to be local to the test, we don't have to worry about race conditions or test state that affects each other. These types of test failures are SUPER difficult to debug when they happen.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jest will never run multiple tests in the same file at the same time (unless you actively specify that they should, using
test.concurrent
) - test parallelism in jest is always about running multiple different files in differentnode
instances at the same time. A file itself will always run top-to-bottom.There can never be any collision between tests - or otherwise, these tests writing on
globalThis
, or any kind of mock, would be incredibly dangerous from the start :)The only way parallelism affects test flimsyness is CPU usage: if the CPU is maxed out, tests just run slower.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats fair. I forget jest parallelism out-of-the-box is per-file, not per test.
My point still remains though that I tend to prefer avoiding shared state between multiple tests because they become impossible to debug if the tests need to run in a certain order to pass.
I like the refactor you did though extracting to a function. You're still able to reduce the boilerplate, but my concern about shared state is gone. Thanks for that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is interesting to me. Based on the implementation and the description in the changeset, I would have expected
aborted
here to befalse
since "theAbortController
will only be.abort()
ed by outside events" (according to the changeset), yet I see no "outside events" in this test.Looking through some of the other tests, perhaps a tweak to the name of the test would help? The fact that the request hasn't completed is relevant here.
My suggestion 👇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sub.unsubscribe();
- tearing down the running link subscription because the result it isn't needed anymore would be that outside event.But yeah, I can tweak the wording a bit :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The more I think about this, the more I think this test isn't needed. It's testing an implementation detail rather than externally observable behavior. I feel like your next 2 tests test the observable behavior you're trying to fix in this PR and is plenty sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's pretty much the "this PR didn't remove intended existing behaviour" test - but I've changed it a bit, so now it should work without touching any implementation details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer if we could test this like the real world to ensure it works as expected.
Yet another reason why I prefer inlining the setup since you'd benefit from not mocking out
AbortController
here 🙂There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with using the unmocked
AbortController
would be that we cannot test if there is ever anew AbortController()
call inside the link - I think mocking of globals is mostly impossible.I'll see what I can do here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually wonder how valuable this test is since its encroaching on the "testing internal implementation details" territory. We should only need to care what the observable end-user effects are, which in this case is that we don't want to abort requests after they've completed. Whether or not we create an abort controller internally or not technically shouldn't matter.
This would solve the "can't mock global" problem since you wouldn't need to check whether something was created internal to the link or not.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll noodle on that for a bit. I feel like it's important to test that the external AbortSignal is not overwritten, so maybe I can adjust the test accordingly.