The latter bolded text (my emphasis) says that whenever you recieve "isready", you must respond with "readyok". There is no option to say "No, I'm not ready!". However, it also says that "this command can be used to wait for the engine to be ready again", which to me suggests that you can see "readyok", and then hold off on responding "isready" until you are actually prepared to perform a search.* isready
this is used to synchronize the engine with the GUI. When the GUI has sent a command or
multiple commands that can take some time to complete,
this command can be used to wait for the engine to be ready again or
to ping the engine to find out if it is still alive.
E.g. this should be sent after setting the path to the tablebases as this can take some time.
This command is also required once before the engine is asked to do any search
to wait for the engine to finish initializing.
This command must always be answered with "readyok" and can be sent also when the engine is calculating
in which case the engine should also immediately answer with "readyok" without stopping the search.
That is two say, there are two ways of viewing isready: #1 is a State Request. The GUI is asking us if we are ready, and its expected that we respond once we are. This might be instant, or upon completion of an existing search. #2 is that isready is really a ping/pong/heartbeat.
I like to see it as #1. In fact, I've coded it as #1, and I've not had any problems until just now, getting reports that one GUI is indeed using the command as #2. It is of no real difference to me, except right now doing it as #1 prevents a GUI or user from trying to launch a search ontop of an already running serach. In my mind, this is your problem and not mine, so it is all fine.