I have a basic HTTP request returning 100 items.
For testing purposes, I want to filter and remain with items X through Y (or custom filter logic by index).
Forget about the n8n version, it is the most basic functionality it doesn’t matter
If you just want to “augment” the items and keep all of them, you could pass everything through a Set Edit Fields node and just add a derived field to each item, using an expression, like this:
Using a Filter node shouldn’t disrupt the item linking. Are you saying you tried that and it wasn’t mapping correctly?
I think the code is ‘includes’, i tried ‘contains’ but it didn’t work
{{ $json.descriptionText.includes('sales').toString() }}
You could also use a switch node I like too, just depends 
when you for example use a google sheets select a single row per item, (also happens with an if node that actually does something and doesn’t pass everything) and also with a filter node that doesn’t filter everything -
after the node that does any kind of filtering, a merge node is required to restore indexed access.
meaning:
manual trigger - create array [1..10] - if item<4 — 4 items + 6 items. Now use even a simple set node - can access items after the if but not before the if.
to access items before the if: must add a merge node and combine on id.
that’s a very convoluted way to do things.
In some cases this is true, but if your workflow proceeds with only the items that continue from a single path out of a filter, if, etc., the correlation to the corresponding item in previous nodes is preserved.
But, if you combine divergent paths, like filtered and non-filtered, or both true and false from an If node, you do need to re-correlated somehow, which is one of the things a Merge node is for. I would agree that it’s an “unusual” way of doing things, but it’s not that convoluted once you understand what’s happening.
please explain why this makes sense, so i understand what kind of nodes require this merge logic and what kind doesn’t
in my mind, it doesn’t make sense to lose indexing after an if. it’s obviously all the same items.
I’m not really following how you expect things to work, but maybe you want the numeric $itemIndex to always be the same (i.e. maybe you are wanting to do your own correlation by list-position). If that’s it, then any node which does not output the same number of items, in the same order as it received them will require some kind of merge logic to line things up again by “array index.”
However, if you are using n8n’s item correlation, and you reference a previous node’s .item, the current-node-item to previous-node-item mapping works. i.e. $('my filter node').item correctly maps to $('some prefilter node').item
