Bug #37153 NDB Cluster reports affected rows incorrectly

Description:
When doing a DELETE operation using a primary key value that does not exist the Cluster incorretly reports 1 affected row. 

How to repeat:
mysql> CREATE TABLE t1 (a int not null primary key, b char(3)) engine = ndb;
Query OK, 0 rows affected (1.24 sec)

mysql> DELETE FROM t1 WHERE a = 200;
Query OK, 1 row affected (0.03 sec)

Can't reproduce with ndb-6.3.10, building ndb-6.3.14 now

ndb-6.3.14 does indeed show 1 affected row, not zero

now building 6.3.11-13 to see where this changed ...

ndb-6.3.10 is the last OK version, the problem exists starting with ndb-6.3.11

Doesn't have to be a DELETE, UPDATE shows problem too, on an empty table (using current 6.3bzr):

mysql> update t1 set vc='something' where id = 28;
Query OK, 1 row affected (0.03 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Fix pushed to 6.3.18 and 6.4.0

Documented in the 5.1.28-ndb-6.3.18 changelog as follows:

        A statement of the form 'DELETE FROM table WHERE primary_key=value'
        or 'UPDATE table WHERE primary_key=value' where there was no row whose 
        primary key column had the stated value appeared to succeed, with the 
        server reporting that 1 row had been changed.
      
        This issue was only known to affect MySQL Cluster NDB 6.3.11 and later
        NDB 6.3 versions.