This is a bit fragile in that it's special handling code for a specific error. But, I'm not sure we want to add more structure to the coordination protocol error messages for just one odd-duck error message.

Without this, many tests will flake due to dropping a benign error message.

@ethanndickson what do you think?

Ah, I was indeed missing thoselog detected at level ERRORs...

All those test failures are in CLI integration tests. We already ignore error logs oncoderdtest for this same reason, is it feasible to ignore agent error logs too (and only in integration tests)?

If not, this sounds fine to me as a warning.

It's feasible, but I worry it's overbroad.

The ready for handshake "errors" aren't "errors" by the criteria we usually use for logs, which is that we definitely know something bad happened, rather than "something bad might have happened, or it might be fine" which is where we usually put WARN logs.

So, I think this behavior is more correct, I'm just not wild about the implementation. But, also not wild about alternative implementations that make the error vs warning explicit in the protocol.

I think it's fine to write as a one-off. If we ever need to communicate more than one type of warning using the protocol, then maybe we reconsider.

Yeah, that's what I was thinking. If we have to start special casing more than one, it will be worth while to make it explicit in the protocol.