After upgrading PHPC and HHVM to 1.4.0-dev, we started seeing some failed tests that were asserting whether a cursor returned by a find command was dead or alive (PHPC-673). If we change the test to use OP_QUERY by connecting to a 3.0 (or earlier) server, it passes. The current logic is:

return (!cursor->sent ||
        (!CURSOR_FAILED (cursor) &&
         !cursor->done &&
         (cursor->rpc.header.opcode == MONGOC_OPCODE_REPLY) &&
         cursor->rpc.reply.cursor_id));

The last change to this code was the addition of CURSOR_FAILED() in a3d0fe2 for CDRIVER-838, which I don't believe is related since it predates 1.4.0-dev.

Some debugging revealed that cursor->rpc.header.opcode is the cause. For a freshly executed query on its first batch (of two), I observed the following:

cursor->sent: 1
CURSOR_FAILED: 0
cursor->done: 0
cursor->rpc.header.opcode: 0
cursor->rpc.reply.cursor_id: 2061799758

We would expect cursor->rpc.header.opcode to be 1 (i.e. MONGOC_OPCODE_REPLY) here, as it is with a legacy OP_QUERY or on any 1.3.x version of libmongoc. This appears to be a regression.