TypeError: undefined is not an object on port.close() when listener is active

[DavutDurgun]

I'm encountering a TypeError: undefined is not an object (evaluating 'window.TAURI_EVENT_PLUGIN_INTERNALS.unregisterListener') when calling port.close() (or port.cancelListen()) after a listener has been set up with port.listen().

If port.close() is called before port.listen(), the error does not occur.

This bug appears to cause serial port listeners to accumulate, leading to multiple receive callbacks for a single incoming message after repeated connect/disconnect cycles.

Environment:

Tauri API: @tauri-apps/api: ^2.5.0

Plugin: tauri-plugin-serialplugin: ^2.12.0

Issue: The plugin's internal listener unregistration seems to fail, resulting in accumulated listeners and an unhandled TypeError during port closure when a listener is active.

Please investigate this issue.

[s00d]

Try version 2.14.0. This issue may occur during reconnection—if the device was disconnected, unListen becomes unavailable. There should be no more errors now; it will just log to the console.

[DavutDurgun]

Hello,

Thank you for your previous response and the suggestion to update to version 2.14.0. I have updated the plugin to ^2.14.0 as advised (@tauri-apps/api version ^2.5.0).

However, unfortunately, the TypeError: undefined is not an object (evaluating 'window.TAURI_EVENT_PLUGIN_INTERNALS.unregisterListener') error still persists and crashes the application. It does not seem to merely log to the console as mentioned.

The signature of the SerialPort.listen method is (method) SerialPort.listen(fn: (...args: any[]) => void, isDecode?: boolean): Promise. This clearly indicates that port.listen() does not return an unlisten function to the consumer. Therefore, the responsibility for managing and unregistering the listener and releasing resources lies entirely with the plugin itself, and this operation is expected to be handled internally within port.close() (or port.cancelListen(), if applicable).

The fact that this TypeError continues to occur consistently during port.close() (or port.cancelListen()) strongly suggests that the plugin's internal cleanup mechanism for listeners is still failing when it attempts to access window.TAURI_EVENT_PLUGIN_INTERNALS.unregisterListener in scenarios where this function is undefined or unavailable, leading to an unhandled exception.

To help you reproduce this, I've prepared a minimal, self-contained test scenario using the SerialPortService we've been discussing. This scenario consistently triggers the error on my end.

`import { SerialPort } from "tauri-plugin-serialplugin";

async function reproduceSerialPortError() {
const config = {
path: "COM1",
baudRate: 9600,
};
let port: SerialPort | null = null;

try {
    port = new SerialPort({
        path: config.path,
        baudRate: config.baudRate,
    });

    await port.open();

    await port.startListening();

    port.listen((data: Uint8Array) => {
        console.log("Data received:", data);
    }, false);  

    // Simulate some work or waiting for data
    await new Promise(resolve => setTimeout(resolve, 3000));

    // This is the line that causes the error
    await port.close();
} catch (error) {
    console.error("An error occurred:", error);
}

}
reproduceSerialPortError();`

Expected Behavior:
The port.close() method should complete successfully without any errors, cleanly unregistering the internal listener(s) and closing the port.

Current Behavior:
The application crashes with the following error during the await port.close(); call:
Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'window.TAURI_EVENT_PLUGIN_INTERNALS.unregisterListener')

This issue severely impacts the ability to reliably manage serial port connections (especially frequent connect/disconnect cycles) and needs urgent investigation.

Thank you again for your continued support.

Best regards,

[s00d]

try v2.16.0

I didn’t feel like digging into the root of the problem — probably some logic error causing the event to be unsubscribed twice. So I just rewrote the event handling.

Now it always removes the listener first before disconnecting, and I also added support for multiple listeners. It should work like this now:

await port.listen((data) => {
  console.log("Listener 1:", data);
});
await port.listen((data) => {
  console.log("Listener 2:", data);
});

Also, listen now returns an unsubscribe function:

const unsubscribe = await port.listen((data) => {
  console.log("Received:", data);
});

unsubscribe();

It should all work properly now.

---

I couldn’t reproduce your example on my side — it might be OS-related. I’m working on a Mac, and your example works perfectly here. Maybe the issue is with some specific hardware on your side.

[DavutDurgun]

Hello,

Thank you for the information and the suggestion to update to v2.16.0. I have updated the plugin to v2.16.0 as advised and integrated the change where port.listen() now returns an unsubscribe function into my SerialPortService code.

However, unfortunately, the error still persists, and it now appears twice in the console output. As you mentioned in your last message, I am still testing on my Mac device. Despite your observation that it works flawlessly on your end, I am encountering this issue. Perhaps, as you suggested, there might be a difference related to specific hardware or software configuration on my side.

The relevant parts of my updated SerialPortService methods (connectPort, readData, and disconnectPort) are as follows:

async connectPort(config: {
    path: string;
    baudRate: number;
  }): Promise<SerialPort> {
    try {
      const port = new SerialPort({
        path: config.path,
        baudRate: config.baudRate,
      });
      await port.open();
      console.log(`SerialPortService: ${config.path} successfully opened.`);
      return port;
    } catch (error) {
      console.error(
        `SerialPortService: ${config.path} connection error:`,
        error,
      );
      throw new Error(
        i18n.t('serialConnectionManager.storeErrors.connectionError', {
          errorMessage: (error as Error).message,
        }),
      );
    }
  }

 async readData(port: SerialPort): Promise<void> {
    console.log('SerialPortService: Starting data listener...');
    try {
      await port.startListening();
      // Assigning the new unsubscribe function to the class property
      this.unsubscribe = await port.listen((data: Uint8Array) => {
        console.log(data) // Logging received data
      }, false);
      console.log('SerialPortService: Data listener established.');
    } catch (error) {
      console.error('SerialPortService: Error in data listening:', error);
      throw new Error(
        `SerialPortService: Failed to start data listening: ${(error as Error).message}`,
      );
    }
  }

async disconnectPort(port: SerialPort | null): Promise<boolean> {
    try {
      if (port?.isOpen) {
        // Calling unsubscribe function if it exists
        if (this.unsubscribe) {
          this.unsubscribe();
        }
        this.onDataCallback = null; // Resetting the callback
        await port.close();
        console.log('SerialPortService: Port successfully closed.');
      } else {
        console.log('SerialPortService: Port is already closed or undefined.');
      }
      return true;
    } catch (error) {
      console.error('SerialPortService: Disconnection error:', error);
      throw new Error(
        i18n.t('serialConnectionManager.storeErrors.disconnectError', {
          errorMessage: (error as Error).message,
        }),
      );
    }
  }

The continued presence of this issue makes it challenging to reliably manage serial port connections. We would appreciate any further assistance or potential solutions you might have, especially considering the OS/hardware differences.

Thank you again for all your responses.

Best regards,

[s00d]

It seems the issue is with Tauri: tauri-apps/tauri#13746. We’ll need to wait until they fix it. On my side, I don’t see any problems. I can try rolling back to version 2.5 if it’s urgent.

[s00d]

I suspect that the plugin was using an outdated integration method, which may have caused some conflicts. I’ve reviewed the plugin template again and updated the code. Please try version v2.17.1 — it might resolve the issue.
If it doesn’t help, then I’ll most likely need to roll back Tauri itself to version 2.5.

Also, please make sure to use Tauri version 2.6.2 when testing — most likely, other versions may cause issues.

[DavutDurgun]

Hello,

Thank you for both of your recent messages and for the continuous updates and suggestions.

As advised, I have updated the tauri-plugin-serialplugin to v2.17.1 and Tauri to 2.6.2 for testing.

I'd like to report that the TypeError: undefined is not an object message still persists in the console. To clarify, the connection has always closed successfully, and resources have been released, despite this error message appearing. The application does not crash due to this error, and the port.close() operation completes as expected in terms of functionality.

Given that the connection functionality works correctly (i.e., the port closes) despite the persistent console error, this is not an urgent issue for us.

Thank you again for your diligent work and support in investigating this. We appreciate your efforts and are happy to assist with any further testing if needed.

Best regards,

[s00d]

Hello,

Thank you for both of your recent messages and for the continuous updates and suggestions.

As advised, I have updated the tauri-plugin-serialplugin to v2.17.1 and Tauri to 2.6.2 for testing.

I'd like to report that the TypeError: undefined is not an object message still persists in the console. To clarify, the connection has always closed successfully, and resources have been released, despite this error message appearing. The application does not crash due to this error, and the port.close() operation completes as expected in terms of functionality.

Given that the connection functionality works correctly (i.e., the port closes) despite the persistent console error, this is not an urgent issue for us.

Thank you again for your diligent work and support in investigating this. We appreciate your efforts and are happy to assist with any further testing if needed.

Best regards,

Yes, I understand that the application doesn’t crash, but this causes memory leaks — the listener is not being cleaned up. Could you try rolling back tauri and @tauri-apps/api to version 2.5 with tauri-plugin-serialplugin 2.17.1 and see if the issue persists? I’ve reconfigured the dependencies on my side, so a rollback might help.

[DavutDurgun]

Retesting with Tauri 2.5 and Plugin 2.17.1
I've followed your advice and rolled back Tauri and @tauri-apps/api to version 2.5, while keeping tauri-plugin-serialplugin at 2.17.1.

Unfortunately, after making these changes and retesting, the issue persists. I'm still observing the same behavior where the TypeError: undefined is not an object (evaluating 'window.TAURI_EVENT_PLUGIN_INTERNALS.unregisterListener') error occurs consistently during the disconnection process.

It seems rolling back Tauri didn't resolve this specific underlying issue with the event listener unregistration that occurs during port.close().

Next Steps
Given that this particular error continues even after rolling back Tauri, it points to a more persistent challenge with the listener cleanup within Tauri's internals. Since you mentioned restructuring your dependencies, perhaps there's another angle to explore or a specific environment detail on my end that might be contributing.

I'm ready to provide any further logs or conduct additional tests if needed. Please let me know how you'd like to proceed.

[s00d]

Retesting with Tauri 2.5 and Plugin 2.17.1 I've followed your advice and rolled back Tauri and @tauri-apps/api to version 2.5, while keeping tauri-plugin-serialplugin at 2.17.1.

Unfortunately, after making these changes and retesting, the issue persists. I'm still observing the same behavior where the TypeError: undefined is not an object (evaluating 'window.TAURI_EVENT_PLUGIN_INTERNALS.unregisterListener') error occurs consistently during the disconnection process.

It seems rolling back Tauri didn't resolve this specific underlying issue with the event listener unregistration that occurs during port.close().

Next Steps Given that this particular error continues even after rolling back Tauri, it points to a more persistent challenge with the listener cleanup within Tauri's internals. Since you mentioned restructuring your dependencies, perhaps there's another angle to explore or a specific environment detail on my end that might be contributing.

I'm ready to provide any further logs or conduct additional tests if needed. Please let me know how you'd like to proceed.

This is very suspicious — have you tried clearing all dependencies, deleting lock files, reinstalling everything, and also running cargo update?

I just couldn't reproduce your issue.

[s00d]

tauri-apps/tauri#13746 (comment)

It seems that the issue is still with the dependencies.