[DRIVERS-430] Test that killCursors really succeeds Created: 05/Dec/17  Updated: 02/Mar/21

Status: Implementing
Project: Drivers
Component/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: newdriver
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on CXX-1479 Test that killCursors really succeeds Backlog
depends on RUST-167 Test that killCursors really succeeds Backlog
depends on CDRIVER-2417 Test that killCursors really succeeds Closed
depends on CSHARP-2119 Test that killCursors really succeeds Closed
depends on GODRIVER-144 Test that killCursors really succeeds Closed
depends on NODE-1214 Test that killCursors really succeeds Closed
depends on PYTHON-1433 Test that killCursors really succeeds Closed
depends on PHPC-1056 Test that killCursors really succeeds Closed
depends on RUBY-1265 Test that killCursors really succeeds Closed
depends on JAVA-2691 Ensure that core driver integration t... Closed
Related
related to SERVER-32169 A cursor created with a session canno... Closed
is related to DOCS-12114 KillCursors for 2.6 and 3.0 Closed
Driver Compliance:
Key Status/Resolution FixVersion
PYTHON-1433 Works as Designed
CDRIVER-2417 Fixed 1.10.0
JAVA-2691 Fixed 3.6.1
NODE-1214 Fixed 3.0.0
SCALA-362 Won't Fix
CSHARP-2119 Fixed 2.9.0
PERL-833 Fixed 2.1.0
RUBY-1265 Fixed 2.7.0.rc0
CXX-1479 Backlog
PHPC-1056 Works as Designed
GODRIVER-144 Done
RUST-167 Backlog
SWIFT-482 Won't Do

 Description   

In SERVER-32169 we noticed that it's easy to miss bugs in drivers' killCursors implementations. The killCursors command can fail but still report "ok: 1", listing the cursor ids it failed to kill in the "cursorsAlive" array:

> db.runCommand({killCursors: "collection", cursors: [NumberLong(0)]})
{
  ok: 1,
  cursorsNotFound: [NumberLong(0)],
  cursorsKilled: [],
  cursorsAlive: []
}

If your driver already includes tests that prove it really can kill a cursor, then you don't need to do anything. For example, PyMongo can't always kill a cursor with MongoDB 3.7.x due to SERVER-32169, and this was discovered because three of PyMongo's tests fail with MongoDB 3.7.x. If you driver has tests which fail due to SERVER-32169 then you may be able to validate this ticket already. Otherwise, here's a suggested test.

Write a test in each driver that checks we really kill a cursor:

  • insert 1000 documents into a collection
  • do a "find" on the collection and iterate the cursor past the first document
  • store the cursor id in a variable
  • assert the cursor id is nonzero
  • kill the cursor (explicitly, or by letting it go out of scope, depending on the driver)
  • assert that the driver receives a server reply to "killCursors" with "ok: 1", an empty "cursorsNotFound" array, an empty "cursorsAlive" array, an empty "cursorsUnknown" array, and a "cursorsKilled" array with one element equal to the cursor id

Drivers can use Command Monitoring, if they've implemented it, to check the server reply.



 Comments   
Comment by Jeffrey Yemin [ 06/Dec/17 ]

Another test suggestion that doesn't involve command monitoring: Do the same setup as suggested in the description, but after killing the cursor manually execute a getMore command on the just-closed cursor and assert that the response is a CursorNotFound error.

Generated at Thu Feb 08 08:21:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.