In reality, this isn’t really a Blynk (app) vs Sketch issue, Any method of externally controlling a sketch should have sketch authority, in as such that “Blynk” could be replaced with “Push button to open elevator door, but even if elevator is not there override and open door”… potentially not a good thing.
Blynk is primarily a remote control conduit for hardware, but as Blynk (app) is susceptible to being disconnected from the link, then the hardware (sketch) should always have the priority.
This has already been determined in other issues wherein connection was lost and hardware stopped working because blynk.begin() became a blocking function, prevented a sketch from running until reconnected. The solution for those that needed it was alternative code using blynk.config() and other commands, to give the sketch primary authority on when/if to run.
Another example is when using Blynk to control a robot, with Blynk being the primary, meant that loss of connection potentially has a moving robot on the loose. Solution is again, sketch priority to make decision based on available (or lack of) communication.
Blynk’s promotion of no coding or limited coding required is only true on the most basic of use cases. More complicated logic control still requires finessing the sketch code into doing what you require.
I feel you will be best suited to map out your infrastructure and sketchflow, with priority on the sketch side, so that if a Blynk (app) button says ON, but pumps don’t run… the sketch determines WHY they don’t run and provides feedback or an alternative function instead of forcing the app button priority.