Problem
Event::Ok is overloaded between two different meanings: it fires for a genuine OK packet (carrying affected_rows / last_insert_id), and it fires again for the EOF that terminates a result set — where those same fields are not row counts at all. The event itself gives no way to tell which situation produced it.
Why it matters
Every host of turnloop-mysql has to track, on its own, whether a result set is currently open in order to interpret an Event::Ok's fields correctly. Get that tracking wrong and a host reads a meaningless affected_rows value as if it were real.
What would fix it
Splitting Event::Ok into two distinct variants (a real OK packet vs. a result-set-terminating EOF), so a host does not need to shadow the protocol's own state just to disambiguate one event.
Problem
Event::Okis overloaded between two different meanings: it fires for a genuine OK packet (carryingaffected_rows/last_insert_id), and it fires again for the EOF that terminates a result set — where those same fields are not row counts at all. The event itself gives no way to tell which situation produced it.Why it matters
Every host of
turnloop-mysqlhas to track, on its own, whether a result set is currently open in order to interpret anEvent::Ok's fields correctly. Get that tracking wrong and a host reads a meaninglessaffected_rowsvalue as if it were real.What would fix it
Splitting
Event::Okinto two distinct variants (a real OK packet vs. a result-set-terminating EOF), so a host does not need to shadow the protocol's own state just to disambiguate one event.