Hints for debugging?

[infojunkie]

I'm debugging some issues in my app that uses midi-json-parser, and I am getting an error:

module.js:33 Uncaught (in promise) Error: Invalid typed array length: 4
    at Worker.<anonymous> (module.js:33:1)

which shows me the following code:

export const createBroker = (brokerImplementation) => {
    const fullBrokerImplementation = extendBrokerImplementation(brokerImplementation);
    return (sender) => {
        const ongoingRequests = createOrGetOngoingRequests(sender);
        sender.addEventListener('message', (({ data: message }) => {
            const { id } = message;
            if (id !== null && ongoingRequests.has(id)) {
                const { reject, resolve } = ongoingRequests.get(id);
                ongoingRequests.delete(id);
                if (message.error === undefined) {
                    resolve(message.result);
                }
                else {
                    reject(new Error(message.error.message));

where line 33 is the last line above.

If I understand correctly, the browser thread of midi-parser-json is receiving this error from the broker (or worker, I don't understand the distinction) and throws the error here.

How can I find the source line where this error occurred? Also, the MIDI file that I am passing to the module works fine elsewhere, so I am not sure how to proceed with debugging.

[chrisguttandin]

Yes, it's a bit tricky to debug since the error happens in the Web Worker. For some reason a typed array gets created with an invalid size.

Could you maybe share the MIDI file which triggers this bug?

[infojunkie]

Could you maybe share the MIDI file which triggers this bug?

I fixed my bug in the meantime, but the point I was trying to make here is about enhancing the debuggability of the module. Even logging the stack trace on the worker side would be a good help.

[chrisguttandin]

I understand that not getting a stack trace on the worker is very annoying. Sadly though I don't know of a good way to include that functionality while developing that would allow the console.log statements to be removed at build time.

I'm still curious what caused the error. I would expect the worker to not throw a cryptic error at all. Can you share what caused the error?

[infojunkie]

I'm still curious what caused the error. I would expect the worker to not throw a cryptic error at all. Can you share what caused the error?

I am serving the MIDI file via an API endpoint, that the host page is accessing via a fetch() call. Because of CORS, I was mistakenly using { mode: 'no-cors' } but as I better read the documentation, it turns out no-cors only returns

Content-Type with a value of application/x-www-form-urlencoded, multipart/form-data, or text/plain

So my MIDI file was being interpreted wrongly on the client side, which problably resulted in unwanted bytes being sent to the MIDI parser here.

I solved that using a webpack dev server proxy setting for my local development.

Sadly though I don't know of a good way to include that functionality while developing that would allow the console.log statements to be removed at build time.

I suggest that keeping a console.error message in the production build is actually desirable if an exception is being thrown - surely better than reporting it on the caller side, which makes it untraceable.

If you insist on removing the console logs in production, you can use grunt to do it.

But I will not argue this point further, since my immediate problem is now solved :smile:

[chrisguttandin]

Thanks a lot for the detailed description.

I think what happened was that the file was interpreted as an ArrayBuffer with 0 bytes which triggered an error here: https://github.com/chrisguttandin/midi-json-parser-worker/blob/9dac828124a3107d8481696741d01da1b2a70b86/src/midi-file-parser.ts#L88 ... that came from here: https://github.com/chrisguttandin/midi-json-parser-worker/blob/9dac828124a3107d8481696741d01da1b2a70b86/src/helpers/stringify.ts#L7

Running new Uint8Array(new ArrayBuffer(0), 0, 4) throws the same error. I will add a fix to catch this error and to report it in a meaningful way.