Filtering node seems to fail frequently

[c_347]

In workflows with a large number of items, the filter node seems to fail and return an impossible number of items as the output. For example, in the screenshot below, there are 100 items, and the filter reports that 27 pass the filter and 27 fail. This pattern seems consistent–i.e., when the filter node fails, it always reports an equal number of items passing through vs. failing which do not sum to the actual number of items. It seems somewhat more common in workflows with pinned data, but happens with unpinned data as well. Re-running the filter node a few times usually fixes it in the workflow builder, but it seems as if this node fails in production and doesn’t trigger an error, so it causes failures which are not easy to catch or automatically re-run.

If this is a known error with a functional solution, would be interested in learning how to implement it. It seems it may simply be a bug, however.

Screenshot

Information on your n8n setup

• n8n version: Self-hosted version 1.26.0
• Database (default: SQLite): Render PostgreSQL (15)
• n8n EXECUTIONS_PROCESS setting (default: own, main): own, main
• Running n8n via (Docker, npm, n8n cloud, desktop app): Docker/Render

[ihortom]

@c_347 , I would suggest you to ensure that the dates you compare are of the same format and are actually dates. From the screenshot, I can conclude that you compare string representation of the dates. That is why you have inconsistent results.

What I mean is, convert your strings to the same Date object. You can use either native JavaScript Date or supported Luxon’s DateTime object. For example, not just {{ $json.completedTime }} but {{ DateTime.fromISO($json.completedTime) }}. The same goes to the other value you are comparing this one with.

[c_347]

I appreciate the feedback, and have implemented the recommended fix.

I believe I’ve observed this with other filter nodes where there were not any issues like this (e.g. string includes/does not include), but will make sure to check for mismatches like .fromISO vs DateTime.fromISO($datetime) or unconverted strings.