-
-
Notifications
You must be signed in to change notification settings - Fork 522
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
TypeError: myFile?.slice(...).arrayBuffer is not a function #2273
Comments
Hi everyone, I also have all tests broken but with a different error, adding here for simplicity but I'm OK to open a new issue if you want. I'm upgrading from 4.2.2 to 4.2.4 and I'm using Vitest as my test runner. Stacktrace: TypeError: unusable Thanks, |
We encounter the same issue as @ddolcimascolo after upgrading from 2.4.2 to 2.4.2 (we're also using Vitest). Edit: Fix versions, thanks @corneliusroemer :) |
@ddolcimascolo, this one looks related to mswjs/interceptors#630. |
I think you all mean 2.4.2 not 4.2.2 🙃 |
Indeed 😅 |
Seems to also break the Request type
The headers on the request object have changed from a Headers object where |
None of these errors look MSW related (at least directly). I highly recommend you check your Node.js versions because MSW in no shape or form influences how Request/Response/Headers function. |
Tested v2.4.3, no issue, the upgrade from v2.4.3 to v2.4.4 break the previous behaviour |
Using resolution to downgrade the transitive dependency on |
By bisecting I arrived at the same
|
Seeing the same issue as @ddolcimascolo on 2.4.4. Also using
Downgrading |
I had the same issue using Vitest after upgrading MSW from 2.2.0 to 2.4.5 (and 2.4.4). It works correctly in 2.4.3, though...
|
…t not interceptors) (#2766) * deps(website): update headlessui and add jsdom polyfill see: - tailwindlabs/headlessui#3473 - tailwindlabs/headlessui#3469 * Update msw, pinning transitive dep msw interceptors to 0.33.3 for the time being see: - mswjs/msw#2273
The |
Just released https://github.com/mswjs/msw/releases/tag/v2.4.6. Can someone please update and let me know if this issue is resolved? Thanks. |
Yep. Renovate will pick it up for our repo later today, I'll report back here |
@kettanaito I can confirm that this specific issue is resolved in v2.4.6 I have two failing tests, though, where the response body looks Thanks for the great work ! David |
The failing tests were on my side. Thanks again ! |
All fixed for me too - thanks @kettanaito! ❤️ |
Awesome! Thanks for a swift confirmation. Would love to hear whether that also fixed the |
@kettanaito the issue with myFile?.slice() is related to msw interceptors - if I pin it to 0.33.3 then I can upgrade msw to 2.4.6 - but if I just bump msw without pinning the issue continues to exist |
TypeError: myFile?.slice(...).arrayBuffer is not a function
TypeError: myFile?.slice(...).arrayBuffer is not a function
TypeError: myFile?.slice(...).arrayBuffer is not a function
UpdateSharing some info I found on this issue below. Root causeThe issue is introduced in mswjs/interceptors#613, caused by calculating the total request body size here. Reading the In fact, I cannot read the intercepted I still don't understand how that causes Behavior changeSince we are now correctly calculating the XMLHttpRequest total body size to support upload events, your request body is being read internally during that test (previously, it wasn't). @corneliusroemer, can you please tell me more about what's the form data in that failing test case? Is there a chance it's invalid/missing? That would cause If I try to read Likely irrelevant observationsImporting from // website/src/components/Submission/SubmissionForm.spec.tsx
import { mockRequest, testAccessToken, testConfig, testGroups, testOrganism } from '../../../vitest.setup.ts'; This itself can cause some issues. I recommend you refactor this, moving the reused things away into a standalone module. |
File/Blob reading methods are undefined even if I don't enable MSW: - beforeAll(() => testServer.listen({ onUnhandledRequest: 'error' }));
+// beforeAll(() => testServer.listen({ onUnhandledRequest: 'error' }));
+console.log('demo:', new File(['content'], 'foo.txt', { type: 'text/plain' }).text());
This strongly suggests that the issue only surfaces through the library, but isn't caused by it. MSW/Interceptors don't establish any side effects before you start them (call UpdateI can confirm that the // your tests
import { File as NativeFile } from 'node:buffer';
console.log(new File(['content'], 'foo.txt', { type: 'text/plain' }) instanceof NativeFile);
// false! // node repl
const { File: NativeFile } = require('node:buffer')
new File(['content'], 'foo.txt', { type: 'text/plain' }) instanceof NativeFile
true If I switch your tests to
const vitestConfig = defineVitestConfig({
test: {
globals: true,
- environment: 'jsdom',
+ environment: 'happy-dom',
setupFiles: ['./vitest.setup.ts'],
include: ['./src/**/*.spec.ts', './src/**/*.spec.tsx'],
},
}); What this means is that sometime during the test run, JSDOM decides not to implement I am closing this as Jest/JSDOM-related issue, which we are not addressing. You can learn more about MSW's stance on Jest/JSDOM support. SolutionTest browser code in the browser. If you can't, use |
Thanks @kettanaito for the thorough investigation and apologies for reporting something that was only indirectly broken by msw with root cause being our wrong usage of some libraries. |
No worries! Appreciate your understanding on this one. It wasn't as obvious as other jsdom issues. Happy to add it to my cursed chest of browser-like environments' quirks. |
Prerequisites
Environment check
msw
versionNode.js version
22.8
Reproduction repository
loculus-project/loculus@c813cd9
Reproduction steps
Current behavior
Getting error:
Expected behavior
No error when doing patch update from 2.4.1 to 2.4.4
The text was updated successfully, but these errors were encountered: