VLAN Discovery crashes MySQL database after update to v1.43

We are running LIbrenms in a distributed-polling type deployment. After updating to v1.43, when the full discovery runs on one of our Cisco devices with a large number of VLANs defined, a large delete SQL query is generated causing memory usage on our MySQL server to skyrocket and the kernel to oom-kill the daemon. The query in question from our error logs: https://gist.github.com/petracvv/73a34584d0ad821b49ed18c48af9a763

I traced this down to the query generation code here: https://github.com/librenms/librenms/blob/e9ff8c48b66c7e821617fe9e8a45feb33a0fb2c4/includes/discovery/vlans.inc.php#L94

If I revert the portion of this commit (https://github.com/librenms/librenms/commit/e9ff8c48b66c7e821617fe9e8a45feb33a0fb2c4) dealing with line 94 of the includes/discovery/vlans.inc.php file, I no longer see the memory problem on the database server.

Is this something that should be reverted or is it a bug in the new list generation code using dbGenPlaceholders?

Full debug output of the failing VLAN module is here: https://gist.github.com/petracvv/917f4a47eab70b1b78ae60e58001f694

Yeah, the query is to remove invalid vlans. Not sure of a better approach to delete them. Do you have any ideas?

Exact same issue here.
This SQL request regularly crash our MySQL server (oom kill, 6Go RAM + 6Go Swap available):

DELETE FROM `ports_vlans` WHERE `device_id`=? AND `port_vlan_id` NOT IN (?,?,?,[huge list] )