I’m totally new to n8n. I installed it on a local virtual machine (Windows 10 22H2) with npm, version 1.121.3 . I use ngrok for tunneling. I started creating a workflow and playing around with nodes, but it constantly (usually within a few minutes for a longer running workflow, but also happened right after restarting n8n or just randomly when writing parameters to nodes) crashes with this error message.
What is the error message (if any)?
Assertion failed: new_time >= loop->time, file src\win\core.c, line 327
Always this, in the console window running n8n.
Please share your workflow
Here’s a sample workflow but it crashed with others too.
Share the output returned by the last node
Either the expected output or no output if it crashes. This workflow usually crashes after 6-700 items into the loop.
Running n8n via (Docker, npm, n8n cloud, desktop app): npm
Operating system: Windows 10 22H2 on VMware player 16
I tried to debug with ChatGPT but after the 6th “here’s the solution which will SURELY work now” I gave it up. It thought that Node.js has a timer bug which causes backward jumps in the timer. It advised to go back to Node.js 20 LTS but n8n needs a newer version.
It may well be a time drift issue that can happen with VMs from the error- it’s from the event-loop. When this happens, is the VM under heavy load? Is it sized properly for n8n? For example, bad things happen when swapping occurs. I would make sure sizing is ok first. Try to add another core + a bit more memory to the VM and see if that helps. Maybe measure to see if it survives a bit longer or a lot longer…. If that’s all fine, then try addressing time synching like: Configuring Time Synchronization Between Guest and Host Operating Systems
The VM itself is not under heavy load, nothing else is running beside n8n. I doubt resources should be a problem: 17 GB memory, 8 cores, 40 GB hard disk. I initially started with 2 cores and 8 GB RAM, but increasing didn’t help. The host is under heavier load, but can it mess with the VM? I presume the VM’s resources are dedicated.
One more thing I noticed during testing: with a very basic (no api calls, only a bit of python code node, like counting to 1000 with a 1s delay each loop) workflow it didn’t crash. But when I started to add more complex things (mostly spotify nodes and google sheet and a few wait nodes to avoid going over rate limits) it became much more frequent. Not on every run, for example going through a 10-20 song tracklist and getting the song is usually working, but going through hundreds of them is crashing all the time, even though wait times are the same.
I think I figured it out. The host had time automatic time sync disabled and the last sync was 1.5 year ago, it was a few minutes off compared to the VM (which was syncing automatically to the windows time server). Even though the VM’s host time sync was disabled, it seems to have caused a problem, because now that I enabled it on the host, it could finish a very long run without error. I’ll test it further but I’m optimistic.
That’s great, @balu027 ! These are common with VMs. I encountered similar issues when I supported a Java-based product life cycle management (PLM) software, where I used VM instances. VM needed to be sized properly for the PLM app + time must be synched with a time server so host + vm should not have different times. Was the doc ( Configuring Time Synchronization Between Guest and Host Operating Systems ) I provided of any use?
Yes, a VM under load due to sizing issues– e.g., Ubuntu with running some massive app that causes massive swapping- may cause a time drift without any syncing to a time server. See timer/timing interupt backlog: https://www.vmware.com/docs/vmware_timekeeping. I must admit that I’m not sure how much better the issue is these days, as I don’t use VM images much now. Both host and vm using a time server to sync times should help.
I couldn’t use the doc directly because I already did the steps it mentioned, but it was helpful as a thought provoker which helped to solve the issue. The sync issue did not appear since, I think it’s resolved now.
