an invalid search filter value is provided in a suitelet. search runs, throws an 'error' in the log, drops the filter, runs the search and provides results (sans filter). no actual error in the code.

wow, haven't seen this and this behavior is horrible at first glance.

it blew my mind (and the better part of my afternoon yesterday). what's worse was i uncovered a weird inconsistency in a particular join type (binonhand) from the item record. running on the client side, 'binnumber' is a textual representation of the bin. running on the server side, it requires it to be the bin id. exact same code, values, etc. except, in this case, instead of failing (or returning no results) it just dropped the damn filter, threw that log message and pretended like nothing happened.

That is awful. It’s like “this is wrong, but we aren’t going to tell you, and we are going to return you some confusing and incorrect results”

my current theory, which i'm sure i'll never get around to testing/validating, is that it's because the join on binonhand has some extra 'magic' behind it, since it's not actually joining to a record type. and maybe the validation they normally use for

invalid search filter

type situations doesn't work, so this is just some shoehorned workaround. (the fact that the 'type's required differ between client and server contexts points to there being some 'magic' too i think.)

I thought this was "normal" behavior... I botched a filter entering employee records a few weeks ago in a suitelet and it went on its merry way, updating every employee record in the system.

that's a whole lot scarier than my use case.

I got really lucky. It was a field that was new and isn't actually being used yet.

holy shit. That’s terrifying.