profile
viewpoint
Shane Harvey ShaneHarvey @mongodb San Francisco, CA

mongodb/mongo-python-driver 3107

PyMongo - the Python driver for MongoDB

mongodb/motor 1536

Motor - the async Python driver for MongoDB and Tornado or asyncio

ajdavis/mongo-mockup-db 33

MockupDB - Simulate a MongoDB server.

mongodb-labs/python-bsonjs 27

A fast BSON to MongoDB Extended JSON converter for Python - This Repository is NOT a supported MongoDB product

jyemin/mongo-java-driver 4

The Java driver for MongoDB

mjsalerno/memguard 4

A utility that acts like valgrind

mjsalerno/StopLeak 3

Stops third party requests that accidentally or intentionally leak Personally Identifiable Information (PII).

ajdavis/pymongo-mockup-tests 2

Test PyMongo with MockupDB - for eventual merge into mongo-python-driver repo.

mongodb/pymongo-auth-aws 2

The Python MONGODB-AWS authentication mechanism for PyMongo

Pull request review commentmongodb/motor

MOTOR-614 Use Python 3 syntax for super() calls

 class C(ABC):         # MOTOR-104, TypeError: Can't instantiate abstract class C with abstract         # methods collection, db, subcollection.         C()++    @asyncio_test+    async def test_inheritance(self):+        class CollectionSubclass(motor_asyncio.AsyncIOMotorCollection):+            pass++        class DatabaseSubclass(motor_asyncio.AsyncIOMotorDatabase):+            def __getitem__(self, name):+                return CollectionSubclass(self, name)++        class ClientSubclass(motor_asyncio.AsyncIOMotorClient):+            def __getitem__(self, name):+                return DatabaseSubclass(self, name)++        cx = ClientSubclass(test.env.uri, **self.get_client_kwargs())+        self.assertIsNotNone(await cx.testdb.testcoll.insert_one({}))

Neat test! One bug is that cx.testdb.testcoll uses __getattr__ not __getitem__. Can we assert that the database and collection are actually DatabaseSubclass and CollectionSubclass?

prashantmital

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventShaneHarvey/mongo-python-driver

Shane Harvey

commit sha fa97adba99717a87614f023ae6bce3053e851d2f

PYTHON-1631 Document new release process

view details

push time in 4 days

create barnchShaneHarvey/mongo-python-driver

branch : document-release-process

created branch time in 4 days

push eventShaneHarvey/mongo-python-driver

Shane Harvey

commit sha 8e7026a83fbda69ad50ffbd382f3e5334272c2dd

PYTHON-2345 Ensure release files can be installed (#487)

view details

push time in 4 days

push eventShaneHarvey/motor

Shane Harvey

commit sha ca6141cb6d07026dcca0b60dc26b103d7fa50186

MOTOR-613 Test contextvars support (#90)

view details

push time in 4 days

delete branch ShaneHarvey/motor

delete branch : MOTOR-613

delete time in 4 days

delete branch ShaneHarvey/mongo-python-driver

delete branch : PYTHON-2345

delete time in 4 days

push eventmongodb/motor

Shane Harvey

commit sha ca6141cb6d07026dcca0b60dc26b103d7fa50186

MOTOR-613 Test contextvars support (#90)

view details

push time in 4 days

PR merged mongodb/motor

MOTOR-613 Test contextvars support

Added a test case inspired by the example in https://github.com/mongodb/motor/pull/88.

+69 -1

0 comment

3 changed files

ShaneHarvey

pr closed time in 4 days

push eventmongodb/mongo-python-driver

Shane Harvey

commit sha 8e7026a83fbda69ad50ffbd382f3e5334272c2dd

PYTHON-2345 Ensure release files can be installed (#487)

view details

push time in 4 days

PR merged mongodb/mongo-python-driver

PYTHON-2345 Ensure release files can be installed

Tested here: https://evergreen.mongodb.com/version/5f61533de3c3314c4c6884ff

+141 -27

1 comment

5 changed files

ShaneHarvey

pr closed time in 4 days

issue commentajdavis/mongo-mockup-db

OSError: [WinError 10038] An operation was attempted on something that is not a socket

Your example needs a slight change in order to work. This works:

import pkg_resources
from pymongo import MongoClient
from mockupdb import *


print("Pymongo version: {}".format(pkg_resources.get_distribution("pymongo").version))
print("MockupDB version: {}".format(pkg_resources.get_distribution("mockupdb").version))
server = MockupDB(request_timeout=10)
port = server.run()
client = MongoClient(server.uri)
print("1st receives/replies: {}".format(server.receives().replies({'ok': 1, 'maxWireVersion': 6})))
with going(client.admin.command, 'ismaster') as future:
    # Reply to the first isMaster (the connection handshake)
    print("2nd receives/replies: {}".format(server.receives().replies({'ok': 1, 'maxWireVersion': 6})))
    # Reply to the second isMaster (the actual command)
    print("3rd receives/replies: {}".format(server.receives().replies({'ok': 1, 'maxWireVersion': 6})))

print("going context mgr finished")

response = future()
print("response: {}".format(response))

Output:

$ python issue36.py
Pymongo version: 3.11.0
MockupDB version: 1.8.0.dev0
1st receives/replies: True
2nd receives/replies: True
3rd receives/replies: True
going context mgr finished
response: {'ok': 1, 'maxWireVersion': 6}
brianminsk

comment created time in 4 days

pull request commentmongodb/mongo-python-driver

PYTHON-2345 Ensure release files can be installed

Just one question - why don't we test with PyPy as well?

I don't test pypy here because we don't publish wheels for pypy. Pypy users will install from the .tar.gz sdist package. I think it's possible to publish pypy wheels we just don't do it yet.

ShaneHarvey

comment created time in 4 days

Pull request review commentmongodb/mongo-python-driver

PYTHON-2345 Ensure release files can be installed

 for VERSION in 2.7 3.4 3.5 3.6 3.7 3.8; do         PYTHON=/Library/Frameworks/Python.framework/Versions/$VERSION/bin/python3     fi     rm -rf build-    $PYTHON setup.py bdist_wheel++    # Install wheel if not already there.

Good point, I opened https://jira.mongodb.org/browse/PYTHON-2375 and https://jira.mongodb.org/browse/BUILD-11842. Since it's tracked in Jira I don't think we need to add a TODO in code.

ShaneHarvey

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventShaneHarvey/motor

Shane Harvey

commit sha 8618d6b73377b11d1d0a3cc6259a9557e287582d

rename contextvar->var

view details

push time in 4 days

Pull request review commentmongodb/motor

MOTOR-613 Test contextvars support

 async def test_list_database_names(self):         self.assertIsInstance(names, list)         self.assertIn(self.collection.database.name, names) +    @unittest.skipIf(not contextvars, 'this test requires contextvars')+    @asyncio_test+    async def test_contextvars_support(self):+        contextvar = contextvars.ContextVar('variable', default='default')++        class Listener(monitoring.CommandListener):+            def __init__(self):+                self.vars = []++            def save_contextvar_value(self):+                self.vars.append(contextvar.get())++            def started(self, event):+                self.save_contextvar_value()++            def succeeded(self, event):+                self.save_contextvar_value()++            def failed(self, event):+                self.save_contextvar_value()++        listener = Listener()+        client = self.asyncio_client(event_listeners=[listener])+        coll = client[self.db.name].test++        await coll.insert_one({})+        self.assertTrue(listener.vars)+        for var in listener.vars:+            self.assertEqual(var, 'default')++        contextvar.set('ContextVar value')

See below where we assert that the listener callbacks have access to the new value. This is the part that tests contextvars get forwarded to the background executors.

ShaneHarvey

comment created time in 4 days

Pull request review commentmongodb/motor

MOTOR-613 Test contextvars support

 async def test_list_database_names(self):         self.assertIsInstance(names, list)         self.assertIn(self.collection.database.name, names) +    @unittest.skipIf(not contextvars, 'this test requires contextvars')+    @asyncio_test+    async def test_contextvars_support(self):+        contextvar = contextvars.ContextVar('variable', default='default')++        class Listener(monitoring.CommandListener):+            def __init__(self):+                self.vars = []++            def save_contextvar_value(self):+                self.vars.append(contextvar.get())++            def started(self, event):+                self.save_contextvar_value()++            def succeeded(self, event):+                self.save_contextvar_value()++            def failed(self, event):+                self.save_contextvar_value()

Done.

ShaneHarvey

comment created time in 4 days

Pull request review commentmongodb/motor

MOTOR-613 Test contextvars support

 async def test_list_database_names(self):         self.assertIsInstance(names, list)         self.assertIn(self.collection.database.name, names) +    @unittest.skipIf(not contextvars, 'this test requires contextvars')+    @asyncio_test+    async def test_contextvars_support(self):+        contextvar = contextvars.ContextVar('variable', default='default')++        class Listener(monitoring.CommandListener):+            def __init__(self):+                self.vars = []++            def save_contextvar_value(self):+                self.vars.append(contextvar.get())++            def started(self, event):+                self.save_contextvar_value()++            def succeeded(self, event):+                self.save_contextvar_value()

This is actually the use case we want to test. set() doesn't work like that because the executor gets a copy of the context. The listener callbacks can make modifications to the context but those changes won't be reflected in the original context.

ShaneHarvey

comment created time in 4 days

Pull request review commentmongodb/motor

MOTOR-613 Test contextvars support

 async def test_list_database_names(self):         self.assertIsInstance(names, list)         self.assertIn(self.collection.database.name, names) +    @unittest.skipIf(not contextvars, 'this test requires contextvars')+    @asyncio_test+    async def test_contextvars_support(self):+        contextvar = contextvars.ContextVar('variable', default='default')

Renamed to "var".

ShaneHarvey

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentmongodb/mongo-python-driver

PYTHON-2345 Ensure release files can be installed

 for VERSION in 2.7 3.4 3.5 3.6 3.7 3.8; do         PYTHON=/Library/Frameworks/Python.framework/Versions/$VERSION/bin/python3     fi     rm -rf build-    $PYTHON setup.py bdist_wheel++    # Install wheel if not already there.

This was needed to fix this error:

+ /System/Library/Frameworks/Python.framework/Versions/2.7/bin/python setup.py bdist_wheel
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'python_requires'
  warnings.warn(msg)
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help
error: invalid command 'bdist_wheel'

https://evergreen.mongodb.com/task/mongo_python_driver_Release__platform~macos_1014_release_patch_e1915fc89ba01f4f22f2a3ad1074978ff0fdf5b4_5f6145e1562343460ae4523e_20_09_15_22_53_41

ShaneHarvey

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

PR opened mongodb/motor

Reviewers
MOTOR-613 Test contextvars support

Added a test case inspired by the example in https://github.com/mongodb/motor/pull/88.

+69 -1

0 comment

3 changed files

pr created time in 5 days

create barnchShaneHarvey/motor

branch : MOTOR-613

created branch time in 5 days

push eventShaneHarvey/motor

Bulat Khasanov

commit sha e2d0e18c51cd2d0f11dbff2bd3139d6e40d8519e

MOTOR-613 Add contextvars support (#88)

view details

push time in 5 days

pull request commentmongodb/motor

MOTOR-613: Add contextvars support

Thanks @khasanovbi!

khasanovbi

comment created time in 5 days

push eventmongodb/motor

Bulat Khasanov

commit sha e2d0e18c51cd2d0f11dbff2bd3139d6e40d8519e

MOTOR-613 Add contextvars support (#88)

view details

push time in 5 days

PR merged mongodb/motor

MOTOR-613: Add contextvars support

Add support to context vars.

This may be useful for logging, e.g. pass trace params like request_id to CommandLogger

+20 -0

3 comments

2 changed files

khasanovbi

pr closed time in 5 days

push eventShaneHarvey/motor

Prashant Mital

commit sha 5053f219d6216d2e078fd89866d13812e7439994

BUMP 2.3.0.dev0 (#87)

view details

push time in 5 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentmongodb/motor

MOTOR-614 Use Python 3 syntax for super() calls

 def create_class_with_framework(cls, framework, module_name):     cls_dict = dict(cls.__dict__)     cls_dict.pop('__dict__', None) -    new_class = type(str(motor_class_name), cls.__bases__, cls_dict)+    new_class = type(str(motor_class_name), (cls,), cls_dict)

I think we may be able to replace cls_dict with {} now.

prashantmital

comment created time in 5 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentmongodb/specifications

Add heartbeatFrequencyMS default value for retryable read/writes and transaction tests.

 data. Speeding Up Tests ----------------- -Drivers may benefit reducing `minHeartbeatFrequencyMS`_ in order to speed up-tests. Python was able to decrease the run time of the tests greatly by lowering-the SDAM's ``minHeartbeatFrequencyMS`` from 500ms to 50ms, thus decreasing the-waiting time after a "not master" error:+Drivers can greatly reduce the execution time of tests by setting `heartbeatFrequencyMS`_+and `minHeartbeatFrequencyMS`_ (internally) to a small value (e.g. 5ms), below what+is normally permitted in the SDAM spec. If a test specifies an explicit value for+heartbeatFrequencyMS (e.g. client or URI options), drivers SHOULD use that value.

drivers SHOULD use that value -> drivers MUST use that value

DmitryLukyanov

comment created time in 5 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentajdavis/mongo-mockup-db

OSError: [WinError 10038] An operation was attempted on something that is not a socket

Instead of responding to each ismaster command manually I suggest adding an auto responder with server.autoresponds. Responding to each ismaster command manually requires a detailed knowledge of driver internals. For example, your example hangs because this line blocks waiting for the server to respond. Instead you need to use going() like this:

client.admin.command('ismaster')  # hangs here
with going(client.admin.command, 'ismaster') as future:
    # Reply to the first isMaster (the connection handshake)
    server.receives().replies({'ok': 1, 'maxWireVersion': 6})
    # Reply to the second isMaster (the actual command)
    server.receives().replies({'ok': 1, 'maxWireVersion': 6})

Check out the test suite for more examples: https://github.com/ajdavis/mongo-mockup-db/blob/873e05c/tests/test_mockupdb.py#L366-L367

You may also be interested in https://github.com/ajdavis/pymongo-mockup-tests/ where we use this library to test the correctness of pymongo.

brianminsk

comment created time in 5 days

PR opened mongodb/mongo-python-driver

Reviewers
PYTHON-2345 Ensure release files can be installed

Tested here: https://evergreen.mongodb.com/version/5f61533de3c3314c4c6884ff

+141 -27

0 comment

5 changed files

pr created time in 6 days

create barnchShaneHarvey/mongo-python-driver

branch : PYTHON-2345

created branch time in 6 days

push eventShaneHarvey/mongo

Gabriel Marks

commit sha 550a9ee713078ec583621a0d6c368a6bc6ce43d2

SERVER-49131 SSL Info logging for Windows

view details

Pierlauro Sciarelli

commit sha d760da5e25d5de81fc144e818fb612661adb4728

SERVER-48717 Implement the persist/recover functionalities of the VectorClock [last additional changes]

view details

Justin Seyster

commit sha 8b9af875a947b862c6bf82754ae7eaf582a9ab3f

SERVER-48721 Correct ticket number in TODO comment

view details

PV99

commit sha cfd99814027a4972be64742b3dd3de2695c88b84

SERVER-48877 Create an APIParameters class

view details

Vesselina Ratcheva

commit sha 8d6112714189fdb6c652ad06a9496c5ade6c0cdc

SERVER-48816 Make a TenantDatabaseCloner skeleton class

view details

Marcos José Grillo Ramírez

commit sha 5ed7de1446262088dfa8ea420a7d9af4d92ceed7

SERVER-49311 Prevent the PeriodicShardedIndexConsistencyChecker cause failures on tests that require no metadata refresh to be performed until needed

view details

Annie Black

commit sha 4aa1a5d5d49e13d1080b1d73eb4ba79b49e1acb2

SERVER-42071 mark notary client errors as failed

view details

William Schultz

commit sha 9238911d0a46f26419ecdbec4293457b9e1a891d

SERVER-47845 Clean up structure and readability of stable optime calculation logic

view details

Henrik Edin

commit sha 00fbc981646d9e6ebc391f45a31f4070d4466753

SERVER-38987 Replace ephemeralForTest storage engine with biggie implementation ephemeralForTest is now a document level locking engine unittests instantiate the oplog as it is required with doc-level locking engines Added a 'incompatible_with_eft' tag for tests that don't work with this engine for different reasons. Many concurrency suites are disabled due to excessive memory usage

view details

William Schultz

commit sha 4d896861c7b2e3c93b43001693ddd5c6faa10ff7

SERVER-49418 Replication architecture guide changes for removal of the stable optime candidates list

view details

Andrew Morrow

commit sha 64ca473943adf524718b528acafaf90874ce59e4

SERVER-48893 Allow concurrent execution of the core TG on dynamic builders

view details

Billy Donahue

commit sha 95ce0f4ab60e48d0e37a9fba493f6385cdea0821

SERVER-48952 Improve stacktrace-related log messages

view details

Pavi Vetriselvan

commit sha 3bfbd4f8add70ec14a71f6907bafe20f648fc4bc

SERVER-49683 catchup_takeover_two_nodes_ahead.js should use initiateWithHighElectionTimeout()

view details

Spencer T Brody

commit sha c107304153883baaa1c97a9caa5826df9889038c

SERVER-49235 Add PrimaryOnlyServiceRegistry and basic PrimaryOnlyService interface.

view details

Mina Mahmood

commit sha 862afcee565df7ea85f509ba6932f2b70e01afa0

SERVER-49115 Moved OCSP's global state into SSLManagerOpenSSL

view details

Gabriel Marks

commit sha 800524cff59a23d93e30bfc931042cfb03e5ff76

SERVER-49116 Add rotateCertificates command

view details

Benety Goh

commit sha 2a4a2def40803f7dbdfa3ec21f0c178a5a16e259

SERVER-49521 fix writeConcern for non-txn createIndexes commands in core/txns tests

view details

Ryan Egesdahl

commit sha 4635320ea16bb9217605b7150461561fdded5e22

Revert "SERVER-48443 Fix builds with Icecream 1.2+ and gcc 4.4+" This reverts commit 01dd381f3359c44bbc9338d91371d1ff823bb7d8.

view details

Ryan Egesdahl

commit sha f69c932697877c4036aca066cf212eaad55be070

SERVER-48443 Fix builds with Icecream 1.2+ and gcc 4.4+ A bug spotted in Icecream 1.2+ can cause build failures when building with gcc. This is, in turn, due to a bug in GCC where the preprocessor executed via `gcc -E` has different behavior than the one used internally during compilation. We are working with Icecream, and GCC to address these problems. For now, we work around the bugs. * GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475 * Icecream bug report: icecc/icecream#550

view details

Charlie Swanson

commit sha b58968562034c206cd041c083d1ac3cc5e749ec1

SERVER-49690 Retry "CappedPositionLost" to find oldest oplog entry

view details

push time in 6 days

Pull request review commentmongodb/specifications

Add heartbeatFrequencyMS default value for retryable read/writes and transaction tests.

 control the fail point's behavior. ``failCommand`` supports the following   blocked for. Required when blockConnection is true.   `New in mongod 4.3.4 <https://jira.mongodb.org/browse/SERVER-41070>`_. +Speeding Up Tests+=================++Drivers should set the default heartbeatFrequencyMS to 5ms in order to take into account the latest changes regarding streaming protocol. If a test has an explicit heartbeatFrequencyMS value, drivers should use the explicit value.

Thanks for testing that. I second Jermey's request that we mention Drivers may reduce minHeartbeatFrequencyMSas well (if possible in the language). Note that we will not require drivers to reduce minHeartbeatFrequencyMS, nor force drivers to make minHeartbeatFrequencyMS configurable by users (because it shouldn't be). We can just suggest it as a possible way to speed up slow tests.

DmitryLukyanov

comment created time in 6 days

PullRequestReviewEvent

push eventShaneHarvey/mongo-python-driver

Shane Harvey

commit sha e1915fc89ba01f4f22f2a3ad1074978ff0fdf5b4

PYTHON-2372 Build macOS releases in Evergreen (#486)

view details

push time in 6 days

push eventmongodb/mongo-python-driver

Shane Harvey

commit sha e1915fc89ba01f4f22f2a3ad1074978ff0fdf5b4

PYTHON-2372 Build macOS releases in Evergreen (#486)

view details

push time in 6 days

PR merged mongodb/mongo-python-driver

PYTHON-2372 Build macOS releases in Evergreen

Tested here: https://evergreen.mongodb.com/version/5f5c16890305b97395debec5

Here are the new files:

[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp27-cp27m-macosx_10_14_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp34-cp34m-macosx_10_6_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp35-cp35m-macosx_10_6_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp36-cp36m-macosx_10_6_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp37-cp37m-macosx_10_6_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp38-cp38-macosx_10_9_x86_64.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-py2.7-macosx-10.14-intel.egg
+6 -3

0 comment

2 changed files

ShaneHarvey

pr closed time in 6 days

push eventShaneHarvey/cpython

Inada Naoki

commit sha 270b4ad4df795783d417ba15080da8f95e598689

bpo-36346: Doc: Update removal schedule of legacy Unicode (GH-21479) See PEP 623 for detail.

view details

Batuhan Taskaya

commit sha 8f4380d2f5839a321475104765221a7394a9d649

bpo-40726: handle uninitalized end_lineno on ast.increment_lineno (GH-20312)

view details

Victor Stinner

commit sha 15edaecd97a3f8e82895046462342d8ddd8b9f1b

bpo-40989: Fix compiler warning in winreg.c (GH-21722) Explicitly cast PyHKEYObject* to PyObject* to call _PyObject_Init().

view details

Eric L. Frederich

commit sha 52f98424a55e14f05dfa7483cc0faf634a61c9ff

bpo-41482: Fix error in ipaddress.IPv4Network docstring (GH-21736)

view details

Hai Shi

commit sha 79bb2c93f2d81702fdf1f93720369e18a76b7d1a

bpo-40275: Use new test.support helper submodules in tests (GH-21743)

view details

Steve Dower

commit sha 777b611c8c5676b80898a429f71d28e59bddc49d

bpo-41492: Fixes the description appearing in UAC prompts on Windows (GH-21754)

view details

Nathan M

commit sha 5f0769a7529fcbc28190864f098f192053a10747

bpo-41371: Handle lzma lib import error in test_zoneinfo.py (GH-21734)

view details

Inada Naoki

commit sha d9323a8c6e07071a59dc4c910661db33236c01b2

bpo-41493: Refactoring dictresize (GH-21751) Split newsize calculation into new function. dictresize() now accepts exact newsize.

view details

pxinwr

commit sha 3405e0542839cde94df9833b3809710a67a33c7c

bpo-41440: add os.cpu_count() support for VxWorks RTOS (GH-21685)

view details

Zackery Spytz

commit sha 54636355805dd2877bb54fbad8d967e1ddd8b553

bpo-39871: Fix an error in a news entry (GH-21749)

view details

Inada Naoki

commit sha 46e19b61d31ba99f049258efa4ff1334856a3643

bpo-41098: Doc: Add missing deprecated directives (GH-21162) PyUnicodeEncodeError_Create has been deprecated with `Py_DEPRECATED` macro. But it was not documented.

view details

Hai Shi

commit sha 598a951844122678de2596dbc1e0e09e2be65fd2

bpo-40275: Use new test.support helper submodules in tests (GH-21764)

view details

Victor Stinner

commit sha f44693eaed3b9d91a6e415d48224fd4750b59366

bpo-41477: Make ctypes optional in test_genericalias (GH-21766)

view details

Victor Stinner

commit sha e27a51c11e10d5df79b3e48dc3e7bfedfad5a794

bpo-41473: Skip test_gdb with gdb 9.2 to work around gdb bug (GH-21768) gdb 9.2 on Fedora Rawhide is not reliable, see: * https://bugs.python.org/issue41473 * https://bugzilla.redhat.com/show_bug.cgi?id=1866884

view details

Hai Shi

commit sha fcce8c649a14f7a81fae82f9f203bb5b5ee0c205

bpo-40275: Use new test.support helper submodules in tests (GH-21772)

view details

Steve Dower

commit sha 102b4988b1a10d5a61034381aea15521d17c210c

Update Azure Pipelines build to use Ubuntu 18.04 and move triggers into YAML files (GH-21776)

view details

Benjamin Kane

commit sha 705f14556545699ab615ec98f707b438f9603767

Doc: Add a link to tutorial page from `open()` doc (GH-21737) Adds a link to the "Reading and Writing Files" page so users can more easily discover how file handles are handled with the `with` context manager vs without it.

view details

Konge

commit sha a4084b9d1e40c1c9259372263d1fe8c8a562b093

bpo-41497: Fix potential UnicodeDecodeError in dis CLI (GH-21757)

view details

Hai Shi

commit sha d94af3f7ed98e6bfb4bf5f918f464b5e23d3ed1b

bpo-40275: Remove test helpers aliases in test.support (GH-21771)

view details

Hai Shi

commit sha c6f282f3b1cb6da6febc3b8b6d2dc1ef714dbbf7

bpo-40275: Use new test.support helper submodules in tests (GH-21785)

view details

push time in 7 days

issue commentajdavis/mongo-mockup-db

OSError: [WinError 10038] An operation was attempted on something that is not a socket

Yes the timeout behavior is not intuitive. We should document this quirk.

The new error AssertionError: expected to receive Request(), got nothing is discussed in brief here: https://mockupdb.readthedocs.io/tutorial.html#wait-for-a-request-impatiently

You can pass a larger timeout to receives() or a larger request_timeout when creating the MockupDB server: https://mockupdb.readthedocs.io/reference.html?highlight=request_timeout#mockupdb.MockupDB

brianminsk

comment created time in 7 days

issue openedpyca/cryptography

Python 3.9 support

3.9.0rc1 was released 2020-8-11: https://www.python.org/downloads/release/python-390rc1/ 3.9.0 is planned to be released on Monday, 2020-10-05: https://www.python.org/dev/peps/pep-0596/#schedule

I'm not sure if the rc version is available on Travis but you can test out the "3.9-dev" version if you want to get a head start on 3.9 support: https://docs.travis-ci.com/user/languages/python/#python-versions

created time in 7 days

delete branch ShaneHarvey/mongo-python-driver

delete branch : PYTHON-2262

delete time in 7 days

push eventShaneHarvey/mongo-python-driver

Shane Harvey

commit sha 1b97eddfbd4414bf28955d84a97cb93865e37d40

PYTHON-2262 Test Python 3.9 in Evergreen (#485)

view details

push time in 7 days

push eventmongodb/mongo-python-driver

Shane Harvey

commit sha 1b97eddfbd4414bf28955d84a97cb93865e37d40

PYTHON-2262 Test Python 3.9 in Evergreen (#485)

view details

push time in 7 days

PR merged mongodb/mongo-python-driver

PYTHON-2262 Test Python 3.9 in Evergreen

This change adds testing for Python 3.9 and fixes:

[2020/09/10 20:55:18.185] FAIL [0.002s]: test_instantiation (test_custom_types.TestBSONTypeEnDeCodecs)
[2020/09/10 20:55:18.185] ----------------------------------------------------------------------
[2020/09/10 20:55:18.185] TypeError: Can't instantiate abstract class testcodec with abstract method transform_python
[2020/09/10 20:55:18.185] During handling of the above exception, another exception occurred:
[2020/09/10 20:55:18.185] Traceback (most recent call last):
[2020/09/10 20:55:18.185]   File "/data/mci/183724bc86e179ad6d136f6b74916c26/src/test/test_custom_types.py", line 270, in test_instantiation
[2020/09/10 20:55:18.185]     run_test(TypeEncoder, {'python_type': MyType,}, fail=True)
[2020/09/10 20:55:18.185]   File "/data/mci/183724bc86e179ad6d136f6b74916c26/src/test/test_custom_types.py", line 263, in run_test
[2020/09/10 20:55:18.185]     codec()
[2020/09/10 20:55:18.185] AssertionError: "Can't instantiate abstract class .* with abstract methods .*" does not match "Can't instantiate abstract class testcodec with abstract method transform_python"

I've opened https://jira.mongodb.org/browse/PYTHON-2365 and https://jira.mongodb.org/browse/PYTHON-2366 as follow up work to test snappy, FLE, and OCSP. You'll notice this is also based on https://github.com/mongodb/mongo-python-driver/pull/484 to get the tests green.

+45 -9

1 comment

4 changed files

ShaneHarvey

pr closed time in 7 days

pull request commentmongodb/mongo-python-driver

PYTHON-2262 Test Python 3.9 in Evergreen

Rebased to remove the "PYTHON-2362 Use dnspython<2.0 to avoid timeouts" commit which was already merged.

ShaneHarvey

comment created time in 7 days

push eventShaneHarvey/mongo-python-driver

Shane Harvey

commit sha c54974067772f268a9a9dc6dbba0a490e6b8e842

PYTHON-2362 Use dnspython<2.0 to avoid timeouts (#484)

view details

Shane Harvey

commit sha fcb6a8ecbc98fceca138d74fb09b516b172bb4e0

PYTHON-2262 Test Python 3.9 in Evergreen

view details

push time in 7 days

delete branch ShaneHarvey/mongo-python-driver

delete branch : PYTHON-2362

delete time in 7 days

pull request commentandrix/python-snappy

Fix Python 3.8+ DeprecationWarning: PY_SSIZE_T_CLEAN will be required for # formats

Thanks, the Travis job is now showing up again, looks like it worked!

I'm getting and error when building, a failure when testing.

Are you referring to the PyPy failure? If so that failure is also happening on master so it appears to be an unrelated bug:

ERROR: test_decompression (test_snappy.SnappyStreaming)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/andrix/python-snappy/test_snappy.py", line 229, in test_decompression
    decompressor.decompress(compressed_data[split1:split2]) +
  File "/home/travis/build/andrix/python-snappy/snappy/snappy.py", line 235, in decompress
    raise UncompressError("stream missing snappy identifier")
UncompressError: stream missing snappy identifier
ShaneHarvey

comment created time in 7 days

pull request commentandrix/python-snappy

Fix Python 3.8+ DeprecationWarning: PY_SSIZE_T_CLEAN will be required for # formats

It seems the Travis CI job is not displayed here on the PR but it did actually run (the PyPy failure already exists on master): https://travis-ci.org/github/andrix/python-snappy/builds/726109324

I've faced this issue before (travis not showing up for PRs) and fixed it by:

  • Go to your account at https://travis-ci.org/account/repositories
  • Press "sync account". If you get an error syncing then log out of travis and log back in.
  • Toggle the andrix/python-snappy repro off, then toggle it back on.
  • Github should now display the travis job on PRs again.
ShaneHarvey

comment created time in 9 days

PR opened mongodb/mongo-python-driver

Reviewers
PYTHON-2372 Build macOS releases in Evergreen

Tested here: https://evergreen.mongodb.com/version/5f5c16890305b97395debec5

Here are the new files:

[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp27-cp27m-macosx_10_14_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp34-cp34m-macosx_10_6_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp35-cp35m-macosx_10_6_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp36-cp36m-macosx_10_6_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp37-cp37m-macosx_10_6_intel.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-cp38-cp38-macosx_10_9_x86_64.whl
[2020/09/12 00:32:00.273] pymongo-3.11.1.dev1-py2.7-macosx-10.14-intel.egg
+6 -3

0 comment

2 changed files

pr created time in 10 days

push eventShaneHarvey/mongo-python-driver

Shane Harvey

commit sha dbc4909113f6d61caffbf8a8ddc7c5ceeb666cb7

revert git_tag_only debug change

view details

push time in 10 days

create barnchShaneHarvey/mongo-python-driver

branch : PYTHON-2372

created branch time in 10 days

push eventShaneHarvey/mongo-python-driver

Shane Harvey

commit sha c54974067772f268a9a9dc6dbba0a490e6b8e842

PYTHON-2362 Use dnspython<2.0 to avoid timeouts (#484)

view details

push time in 10 days

create barnchShaneHarvey/mongo-python-driver

branch : PYTHON-2364

created branch time in 10 days

Pull request review commentmongodb/mongo-python-driver

PYTHON-2262 Test Python 3.9 in Evergreen

 def fallback_encoder(value):  class TestBSONTypeEnDeCodecs(unittest.TestCase):     def test_instantiation(self):-        msg = "Can't instantiate abstract class .* with abstract methods .*"+        msg = "Can't instantiate abstract class"

Isn't Can't instantiate abstract class enough to ensure the TypeError is from instantiation?

ShaneHarvey

comment created time in 10 days

PullRequestReviewEvent

push eventmongodb/mongo-python-driver

Shane Harvey

commit sha c54974067772f268a9a9dc6dbba0a490e6b8e842

PYTHON-2362 Use dnspython<2.0 to avoid timeouts (#484)

view details

push time in 10 days

PR merged mongodb/mongo-python-driver

PYTHON-2362 Test with dnspython<2.0 to avoid timeouts

There seems to be a bug in dnspython 2.0 related to SRV lookups. For now we should downgrade to dnspython<2.0 to get the test suite green.

+6 -0

3 comments

1 changed file

ShaneHarvey

pr closed time in 10 days

Pull request review commentmongodb/mongo-python-driver

PYTHON-2362 Test with dnspython<2.0 to avoid timeouts

 if [ -n "$COVERAGE" -a $PYTHON_IMPL = "CPython" ]; then     fi fi +if $PYTHON -c 'import dns'; then+  # Trying with/without --user to avoid:+  # ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.+  $PYTHON -m pip install --upgrade --user 'dnspython<2.0.0' || $PYTHON -m pip install --upgrade 'dnspython<2.0.0'

Because then we might need sudo. This will just be a temporary workaround until the toolchain is updated.

ShaneHarvey

comment created time in 10 days

PullRequestReviewEvent

pull request commentmongodb/mongo-python-driver

PYTHON-2362 Test with dnspython<2.0 to avoid timeouts

Should we cut a 3.11.1 release that pins DNSPython to <2 so that new installs of PyMongo can still talk to Atlas? This seems like a massive issue...

I don't think this is a massive issue and I'm not sure we should do anything else. eventlet>=0.26.1 was released which pins to dnspython<2.0 and pymongo already specifies dnspython<2.0 here:

    extras_require.update({'srv': ["dnspython>=1.16.0,<2.0.0"]})
ShaneHarvey

comment created time in 10 days

pull request commentmongodb/mongo-python-driver

PYTHON-2362 Test with dnspython<2.0 to avoid timeouts

Yes this is an eventlet problem. dnspython 2.0 works fine up until eventlet is imported:

>>> from dns import resolver
>>> resolver.query('_mongodb._tcp.test5.test.build.10gen.cc', 'SRV', lifetime=5)
<stdin>:1: DeprecationWarning: please use dns.resolver.resolve() instead
<dns.resolver.Answer object at 0x7fb575599940>
>>> import eventlet
>>> resolver.query('_mongodb._tcp.test5.test.build.10gen.cc', 'SRV', lifetime=5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ubuntu/venv/lib/python3.8/site-packages/dns/resolver.py", line 1221, in query
    return resolve(qname, rdtype, rdclass, tcp, source,
  File "/home/ubuntu/venv/lib/python3.8/site-packages/dns/resolver.py", line 1205, in resolve
    return get_default_resolver().resolve(qname, rdtype, rdclass, tcp, source,
  File "/home/ubuntu/venv/lib/python3.8/site-packages/dns/resolver.py", line 1043, in resolve
    timeout = self._compute_timeout(start, lifetime)
  File "/home/ubuntu/venv/lib/python3.8/site-packages/dns/resolver.py", line 950, in _compute_timeout
    raise Timeout(timeout=duration)
dns.exception.Timeout: The DNS operation timed out after 5.10618257522583 seconds

This should be fixed by eventlet: https://github.com/eventlet/eventlet/issues/619.

ShaneHarvey

comment created time in 10 days

issue commentajdavis/mongo-mockup-db

OSError: [WinError 10038] An operation was attempted on something that is not a socket

OSError: [WinError 10038] An operation was attempted on something that is not a socket

This error happens when the socket is closed on the remote side and the MongoClient will close the socket if the operation times out (20 seconds by default). For example (on macOS):

>>> from mockupdb import *
>>> server = MockupDB()
>>> port = server.run()
>>> port
51366
>>> from pymongo import MongoClient
>>> client = MongoClient(server.uri)
>>> request = server.receives()
>>> request.command_name
'ismaster'
>>> request.replies({'ok': 1, 'maxWireVersion': 6})
True
>>> 
>>> request = server.receives()
>>> import time
>>> time.sleep(20)  # Sleep 20 seconds to ensure the MongoClient operation times out.
>>> request.replies({'ok': 1, 'maxWireVersion': 6})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/shane/git/mongo-mockup-db/mockupdb/__init__.py", line 442, in replies
    self._replies(*args, **kwargs)
  File "/Users/shane/git/mongo-mockup-db/mockupdb/__init__.py", line 728, in _replies
    super(OpMsg, self)._replies(reply)
  File "/Users/shane/git/mongo-mockup-db/mockupdb/__init__.py", line 542, in _replies
    self._server._log('\t%d\t<-- %r' % (self.client_port, reply_msg))
  File "/Users/shane/git/mongo-mockup-db/mockupdb/__init__.py", line 408, in client_port
    address = self._client.getpeername()
OSError: [Errno 9] Bad file descriptor

By default the MongoClient's ismaster operation times out after 20 seconds. Are you waiting 20 seconds between creating the client (client = MongoClient(server.uri)) and sending the reply request.replies({'ok': 1, 'maxWireVersion': 6})?

Instead of responding to each ismaster command manually I suggest adding an auto responder like this:

>>> from mockupdb import *
>>> server = MockupDB()
>>> port = server.run()
>>> responder = server.autoresponds('ismaster', maxWireVersion=6)
...
brianminsk

comment created time in 10 days

push eventShaneHarvey/python-snappy

Shane Harvey

commit sha 22a6cb1169a526049d176956d13083315f1f6de1

Test Python 3.7 and 3.8 in Travis

view details

push time in 11 days

PR opened andrix/python-snappy

Fix Python 3.8+ DeprecationWarning: PY_SSIZE_T_CLEAN will be required for # formats

Fixes https://github.com/andrix/python-snappy/issues/97.

+2 -1

0 comment

1 changed file

pr created time in 11 days

create barnchShaneHarvey/python-snappy

branch : fix-PY_SSIZE_T_CLEAN

created branch time in 11 days

PR opened mongodb/mongo-python-driver

Reviewers
PYTHON-2262 Test Python 3.9 in Evergreen

This change adds testing for Python 3.9 and fixes:

[2020/09/10 20:55:18.185] FAIL [0.002s]: test_instantiation (test_custom_types.TestBSONTypeEnDeCodecs)
[2020/09/10 20:55:18.185] ----------------------------------------------------------------------
[2020/09/10 20:55:18.185] TypeError: Can't instantiate abstract class testcodec with abstract method transform_python
[2020/09/10 20:55:18.185] During handling of the above exception, another exception occurred:
[2020/09/10 20:55:18.185] Traceback (most recent call last):
[2020/09/10 20:55:18.185]   File "/data/mci/183724bc86e179ad6d136f6b74916c26/src/test/test_custom_types.py", line 270, in test_instantiation
[2020/09/10 20:55:18.185]     run_test(TypeEncoder, {'python_type': MyType,}, fail=True)
[2020/09/10 20:55:18.185]   File "/data/mci/183724bc86e179ad6d136f6b74916c26/src/test/test_custom_types.py", line 263, in run_test
[2020/09/10 20:55:18.185]     codec()
[2020/09/10 20:55:18.185] AssertionError: "Can't instantiate abstract class .* with abstract methods .*" does not match "Can't instantiate abstract class testcodec with abstract method transform_python"

I've opened https://jira.mongodb.org/browse/PYTHON-2365 and https://jira.mongodb.org/browse/PYTHON-2366 as follow up work to test snappy, FLE, and OCSP. You'll notice this is also based on https://github.com/mongodb/mongo-python-driver/pull/484 to get the tests green.

+51 -9

0 comment

5 changed files

pr created time in 11 days

create barnchShaneHarvey/mongo-python-driver

branch : PYTHON-2262

created branch time in 11 days

issue openedandrix/python-snappy

Fix Python 3.8+ DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats

Using python-snappy with Python 3.8 or 3.9 produces this deprecation warning:

DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats

To fix this issue define PY_SSIZE_T_CLEAN before including python.h:

#define PY_SSIZE_T_CLEAN
#include "Python.h"

You will also need to change the type passed to '#' formats from int to Py_ssize_t, eg:

 snappy__is_valid_compressed_buffer(PyObject *self, PyObject *args)
 {
     const char * compressed;
-    int comp_size;
+    Py_ssize_t comp_size;
     snappy_status status;

 #if PY_MAJOR_VERSION >=3
     if (!PyArg_ParseTuple(args, "y#", &compressed, &comp_size))
 #else
     if (!PyArg_ParseTuple(args, "s#", &compressed, &comp_size))
 #endif
...

See https://github.com/python/cpython/commit/0895793194cd5f1153d2a286ed3a4fc876149b16 and https://docs.python.org/3.8/c-api/arg.html#strings-and-buffers, and https://docs.python.org/3.8/whatsnew/changelog.html?highlight=py_ssize_t_clean#id147 for an explanation of the PY_SSIZE_T_CLEAN changes.

PEP 353 -- Using ssize_t as the index type is also worth a read. The "Conversion guidelines" section in particular.

created time in 11 days

fork ShaneHarvey/python-snappy

Python bindings for the snappy google library

fork in 11 days

PR opened mongodb/mongo-python-driver

PYTHON-2362 Use dnspython<2.0 to avoid timeouts

There seems to be a bug in dnspython 2.0 related to SRV lookups. For now we should downgrade to dnspython<2.0 to get the test suite green.

+6 -0

0 comment

1 changed file

pr created time in 11 days

create barnchShaneHarvey/mongo-python-driver

branch : PYTHON-2362

created branch time in 11 days

push eventShaneHarvey/mongo-python-driver

Prashant Mital

commit sha dc94ca628e10011f81310df351b604a0beb559a7

PYTHON-2361 Support parsing as extended JSON representation for subtype 4 binary (#483)

view details

push time in 11 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentmongodb/specifications

DRIVERS-709: Unified Test Format

+===================+Unified Test Format+===================++:Spec Title: Unified Test Format+:Spec Version: 1.0.0+:Author: Jeremy Mikola+:Advisors: Prashant Mital, Isabel Atkinson, Thomas Reggi+:Status: Draft+:Type: Standards+:Minimum Server Version: N/A+:Last Modified: 2020-09-08++.. contents::++--------++Abstract+========++This project defines a unified schema for YAML and JSON specification tests,+which run operations against a MongoDB deployment. By conforming various spec+tests to a single schema, drivers can implement a single test runner to execute+acceptance tests for multiple specifications, thereby reducing maintenance of+existing specs and implementation time for new specifications.++META+====++The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be+interpreted as described in `RFC 2119 <https://www.ietf.org/rfc/rfc2119.txt>`__.++Specification+=============+++Terms+-----++Entity+  Any object or value that is indexed by a unique name and stored in the+  `Entity Map`_. This will typically be a driver object (e.g. client, session)+  defined in `createEntities`_ but may also be a+  `saved operation result <operation_saveResultAsEntity_>`_. Entities are+  referenced throughout the test file (e.g. `Entity Test Operations`_).++Internal MongoClient+  A MongoClient created specifically for use with internal test operations, such+  as inserting collection data before a test, configuring fail points during a+  test, or asserting collection data after a test.+++Schema Version+--------------++This specification and the `Test Format`_ follow+`semantic versioning <https://semver.org/>`__. Backwards breaking changes (e.g.+removing a field, introducing a required field) will warrant a new major+version. Backwards compatible changes (e.g. introducing an optional field) will+warrant a new minor version. Small fixes and internal changes (e.g. grammar,+adding clarifying text to the spec) will warrant a new patch version; however,+patch versions SHOULD NOT alter the structure of the test format and thus SHOULD+NOT be relevant to test files.++Each test file defines a `schemaVersion`_, which test runners will use to+determine compatibility (i.e. whether and how the test file will be+interpreted). Test files are considered compatible with a test runner if their+`schemaVersion`_ is less than or equal to a supported version in the test+runner, given the same major version component. For example:++- A test runner supporting version 1.5.1 could execute test files with versions+  1.0 and 1.5 but *not* 1.6 and 2.0.+- A test runner supporting version 2.1 could execute test files with versions+  2.0 and 2.1 but *not* 1.0 and 1.5.+- A test runner supporting *both* versions 1.5.1 and 2.0 could execute test+  files with versions 1.4, 1.5, and 2.0, but *not* 1.6, 2.1, or 3.0.+- A test runner supporting version 2.0.1 could execute test files with versions+  2.0 and 2.0.1 but *not* 2.0.2 or 2.1. This example is provided for+  completeness, but test files SHOULD NOT need to refer to patch versions (as+  previously mentioned).++Test runners MUST NOT process incompatible files but MAY determine how to handle+such files (e.g. skip and log a notice, fail and raise an error). Test runners+MAY support multiple schema versions (as demonstrated in the example above).++Each major version of this specification will have a corresponding JSON schema+(e.g. `schema-1.json <schema-1.json>`__), which may be used to programmatically+validate YAML and JSON files using a tool such as `Ajv <https://ajv.js.org/>`__.++The latest JSON schema MUST remain consistent with the `Test Format`_ section.+If and when a new major version is introduced, the `Breaking Changes`_ section+must be updated and JSON schema(s) for any previous major version(s) MUST remain+available so that older test files can still be validated. New tests files+SHOULD always be written using the latest version of this specification.+++Entity Map+----------++The entity map indexes arbitrary objects and values by unique names, so that+they can be referenced from test constructs (e.g.+`operation.object <operation_object_>`_). To ensure each test is executed in+isolation, test runners MUST NOT share entity maps between tests. Most entities+will be driver objects created by the `createEntities`_ directive during test+setup, but the entity map may also be modified during test execution via the+`operation.saveResultAsEntity <operation_saveResultAsEntity_>`_ directive.++Test runners MAY choose to implement the entity map in a fashion most suited to+their language, but implementations MUST enforce both uniqueness of entity names+and referential integrity when fetching an entity. Test runners MUST raise an+error if an attempt is made to store an entity with a name that already exists+in the map and MUST raise an error if an entity is not found for a name or is+found but has an unexpected type.++Consider the following examples::++    # Error due to a duplicate name (client0 was already defined)+    createEntities:+      - client: { id: client0 }+      - client: { id: client0 }++    # Error due to a missing entity (client1 is undefined)+    createEntities:+      - client: { id: client0 }+      - session: { id: session0, client: client1 }++    # Error due to an unexpected entity type (session instead of client)+    createEntities:+      - client: { id: client0 }+      - session: { id: session0, client: client0 }+      - session: { id: session1, client: session0 }+++Test Format+-----------++Each specification test file can define one or more tests, which inherit some+top-level configuration (e.g. namespace, initial data). YAML and JSON test files+are parsed as an object by the test runner. This section defines the top-level+keys for that object and links to various sub-sections for definitions of+nested structures (e.g. individual `test`_, `operation`_).++Although test runners are free to process YAML or JSON files, YAML is the+canonical format for writing tests. YAML files may be converted to JSON using a+tool such as `js-yaml <https://github.com/nodeca/js-yaml>`__ .+++Top-level Fields+~~~~~~~~~~~~~~~~++The top-level fields of a test file are as follows:++- ``description``: Required string. The name of the test file.++  This SHOULD describe the common purpose of tests in this file and MAY refer to+  the filename (e.g. "updateOne-hint").++.. _schemaVersion:++- ``schemaVersion``: Required string. Version of this specification to which the+  test file complies. Test runners will use this to determine compatibility+  (i.e. whether and how the test file will be interpreted). The format of this+  string is defined in `Version String`_; however, test files SHOULD NOT need to+  refer to specific patch versions since patch-level changes SHOULD NOT alter+  the structure of the test format (as previously noted in `Schema Version`_).++.. _runOnRequirements:++- ``runOnRequirements``: Optional array of one or more `runOnRequirement`_+  objects. List of server version and/or topology requirements for which the+  tests in this file can be run. If no requirements are met, the test runner+  MUST skip this test file.++.. _createEntities:++- ``createEntities``: Optional array of `entity`_ objects. List of entities+  (e.g. client, collection, session objects) that should be created before each+  test case is executed.++  Test files SHOULD define entities in dependency order, such that all+  referenced entities (e.g. client) are defined before any of their dependent+  entities (e.g. database, session).++.. _initialData:++- ``initialData``: Optional array of one or more `collectionData`_ objects. Data+  that should exist in collections before each test case is executed.++  Before each test and for each `collectionData`_, the test runner MUST drop the+  collection and insert the specified documents (if any) using a "majority"+  write concern. If no documents are specified, the test runner MUST create the+  collection with a "majority" write concern.++.. _tests:++- ``tests``: Required array of one or more `test`_ objects. List of test cases+  to be executed independently of each other.+++runOnRequirement+~~~~~~~~~~~~~~~~++A combination of server version and/or topology requirements for running the+test(s).++Server versions SHALL be compared numerically and do not follow the comparison+rules discussed in `Schema Version`_.++The structure of this object is as follows:++- ``minServerVersion``: Optional string. The minimum server version (inclusive)+  required to successfully run the tests. If this field is omitted, it should be+  assumed that there is no lower bound on the required server version. The+  format of this string is defined in `Version String`_.++- ``maxServerVersion``: Optional string. The maximum server version (inclusive)+  against which the tests can be run successfully. If this field is omitted, it+  should be assumed that there is no upper bound on the required server version.+  The format of this string is defined in `Version String`_.++- ``topologies``: Optional array of strings. One or more of server topologies+  against which the tests can be run successfully. Valid topologies are+  "single", "replicaset", "sharded", and "sharded-replicaset" (i.e. sharded+  cluster backed by replica sets). If this field is omitted, it should be+  assumed that there is no topology requirement for the test.++  When matching a "sharded-replicaset" topology, test runners MUST ensure that+  all shards are backed by a replica set. The process for doing so is described+  in `Determining if a Sharded Cluster Uses Replica Sets`_. When matching a+  "sharded" topology, test runners MUST accept any type of sharded cluster (i.e.+  "sharded" implies "sharded-replicaset", but not vice versa).+++entity+~~~~~~++An entity (e.g. client, collection, session object) that will be created in the+`Entity Map`_ before each test is executed.++This object MUST contain **exactly one** top-level key that identifies the+entity type and maps to a nested object, which specifies a unique name for the+entity (``id`` key) and any other parameters necessary for its construction.+Tests SHOULD use sequential names based on the entity type (e.g. "session0",+"session1").++When defining an entity object in YAML, a `node anchor`_ SHOULD be created on+the entity's ``id`` key. This anchor will allow the unique name to be referenced+with an `alias node`_ later in the file (e.g. from another entity or+`operation`_ document) and also leverage YAML's parser for reference validation.++.. _node anchor: https://yaml.org/spec/1.2/spec.html#id2785586+.. _alias node: https://yaml.org/spec/1.2/spec.html#id2786196++The structure of this object is as follows:++.. _entity_client:++- ``client``: Optional object. Defines a MongoClient object.++  The structure of this object is as follows:++  - ``id``: Required string. Unique name for this entity. The YAML file SHOULD+    define a `node anchor`_ for this field (e.g. ``id: &client0 client0``).++  - ``uriOptions``: Optional object. Additional URI options to apply to the+    test suite's connection string that is used to create this client. Any keys+    in this object MUST override conflicting keys in the connection string.++    Documentation for supported options may be found in the+    `URI Options <../uri-options/uri-options.rst>`__ spec, with one notable+    exception: if ``readPreferenceTags`` is specified in this object, the key+    will map to an array of strings, each representing a tag set, since it is+    not feasible to define multiple ``readPreferenceTags`` keys in the object.++  .. _entity_client_useMultipleMongoses:++  - ``useMultipleMongoses``: Optional boolean. If true and the topology is a+    sharded cluster, the test runner MUST assert that this MongoClient connects+    to multiple mongos hosts (e.g. by inspecting the connection string). If+    false and the topology is a sharded cluster, the test runner MUST ensure+    that this MongoClient connects to only a single mongos host (e.g. by+    modifying the connection string). This option has no effect for non-sharded+    topologies.++  .. _entity_client_observeEvents:++  - ``observeEvents``: Optional array of strings. One or more types of events+    that can be observed for this client. Unspecified event types MUST be+    ignored by this client's event listeners and SHOULD NOT be included in+    `test.expectEvents <test_expectEvents_>`_ for this client.++    Test files SHOULD NOT observe events from multiple specs (e.g. command+    monitoring *and* SDAM events) for a single client. See+    `Mixing event types in observeEvents and expectEvents`_ for more+    information.++    Supported types correspond to the top-level keys (strings) documented in+    `expectedEvent`_ and are as follows:++    - `commandStartedEvent <expectedEvent_commandStartedEvent_>`_++    - `commandSucceededEvent <expectedEvent_commandSucceededEvent_>`_++    - `commandFailedEvent <expectedEvent_commandFailedEvent_>`_++  .. _entity_client_ignoreCommandMonitoringEvents:++  - ``ignoreCommandMonitoringEvents``: Optional array of strings. One or more+    command names for which the test runner MUST ignore any observed command+    monitoring events. The command(s) will be ignored in addition to+    ``configureFailPoint`` and any commands containing sensitive information+    (per the+    `Command Monitoring <../command-monitoring/command-monitoring.rst#security>`__+    spec).++    Test files SHOULD NOT use this option unless one or more command monitoring+    events are specified in `observeEvents <entity_client_observeEvents_>`_.++.. _entity_database:++- ``database``: Optional object. Defines a Database object.++  The structure of this object is as follows:++  - ``id``: Required string. Unique name for this entity. The YAML file SHOULD+    define a `node anchor`_ for this field (e.g. ``id: &database0 database0``).++  - ``client``: Required string. Client entity from which this database will be+    created. The YAML file SHOULD use an `alias node`_ for a client entity's+    ``id`` field (e.g. ``client: *client0``).++  - ``databaseName``: Required string. Database name. The YAML file SHOULD+    define a `node anchor`_ for this field (e.g.+    ``databaseName: &database0Name foo``).++  - ``databaseOptions``: Optional `collectionOrDatabaseOptions`_ object.++.. _entity_collection:++- ``collection``: Optional object. Defines a Collection object.++  The structure of this object is as follows:++  - ``id``: Required string. Unique name for this entity. The YAML file SHOULD+    define a `node anchor`_ for this field (e.g.+    ``id: &collection0 collection0``).++  - ``database``: Required string. Database entity from which this collection+    will be created. The YAML file SHOULD use an `alias node`_ for a database+    entity's ``id`` field (e.g. ``database: *database0``).++  - ``collectionName``: Required string. Collection name. The YAML file SHOULD+    define a `node anchor`_ for this field (e.g.+    ``collectionName: &collection0Name foo``).++  - ``collectionOptions``: Optional `collectionOrDatabaseOptions`_ object.++.. _entity_session:++- ``session``: Optional object. Defines an explicit ClientSession object.++  The structure of this object is as follows:++  - ``id``: Required string. Unique name for this entity. The YAML file SHOULD+    define a `node anchor`_ for this field (e.g. ``id: &session0 session0``).++  - ``client``: Required string. Client entity from which this session will be+    created. The YAML file SHOULD use an `alias node`_ for a client entity's+    ``id`` field (e.g. ``client: *client0``).++  - ``sessionOptions``: Optional object. Map of parameters to pass to+    `MongoClient.startSession <../source/sessions/driver-sessions.rst#startsession>`__+    when creating the session. Supported options are defined in the following+    specifications:++    - `Causal Consistency <../causal-consistency/causal-consistency.rst#sessionoptions-changes>`__+    - `Transactions <../transactions/transactions.rst#sessionoptions-changes>`__++    When specifying TransactionOptions for ``defaultTransactionOptions``, the+    transaction options MUST remain nested under ``defaultTransactionOptions``+    and MUST NOT be flattened into ``sessionOptions``.++- ``bucket``: Optional object. Defines a Bucket object, as defined in the+  `GridFS <../gridfs/gridfs-spec.rst>`__ spec.++  The structure of this object is as follows:++  - ``id``: Required string. Unique name for this entity. The YAML file SHOULD+    define a `node anchor`_ for this field (e.g. ``id: &bucket0 bucket0``).++  - ``database``: Required string. Database entity from which this bucket will+    be created. The YAML file SHOULD use an `alias node`_ for a database+    entity's ``id`` field (e.g. ``database: *database0``).++  - ``bucketOptions``: Optional object. Additional options used to construct+    the bucket object. Supported options are defined in the+    `GridFS <../source/gridfs/gridfs-spec.rst#configurable-gridfsbucket-class>`__+    specification. The ``readConcern``, ``readPreference``, and ``writeConcern``+    options use the same structure as defined in `Common Options`_.++.. _entity_stream:++- ``stream``: Optional object. Defines a stream, as defined in the+  `GridFS <../gridfs/gridfs-spec.rst>`__ spec. Test runners MUST ensure that+  stream is both readable *and* writable.++  This entity is primarily used with `uploadFromStream`_ and+  `uploadFromStreamWithId`_ operations for `bucket`_ entities.++  The structure of this object is as follows:++  - ``id``: Required string. Unique name for this entity. The YAML file SHOULD+    define a `node anchor`_ for this field (e.g. ``id: &stream0 stream0``).++  - ``hexBytes``: Required string. The string MUST contain an even number of+    hexademical characters (case-insensitive) and MAY be empty. The test runner+    MUST raise an error if the string is malformed. The test runner MUST convert+    the string to a byte sequence denoting the stream's readable data (if any).+    For example, "12ab" would denote a stream with two bytes: "0x12" and "0xab".+++collectionData+~~~~~~~~~~~~~~++List of documents that should correspond to the contents of a collection. This+structure is used by both `initialData`_ and `test.outcome <test_outcome_>`_,+which insert and read documents, respectively.++The structure of this object is as follows:++- ``collectionName``: Required string. See `commonOptions_collectionName`_.++- ``databaseName``: Required string. See `commonOptions_databaseName`_.++- ``documents``: Required array of objects. List of documents corresponding to+  the contents of the collection. This list may be empty.+++test+~~~~++Test case consisting of a sequence of operations to be executed.++The structure of this object is as follows:++- ``description``: Required string. The name of the test.++  This SHOULD describe the purpose of this test (e.g. "insertOne is retried").++.. _test_runOnRequirements:++- ``runOnRequirements``: Optional array of on or more `runOnRequirement`_+  objects. List of server version and/or topology requirements for which this+  test can be run. If specified, these requirements are evaluated independently+  and in addition to any top-level `runOnRequirements`_. If no requirements in+  this array are met, the test runner MUST skip this test.++  These requirements SHOULD be more restrictive than those specified in the+  top-level `runOnRequirements`_ (if any). They SHOULD NOT be more permissive.+  This is advised because both sets of requirements MUST be satisified in order+  for a test to be executed and more permissive requirements at the test-level+  could be taken out of context on their own.++.. _test_skipReason:++- ``skipReason``: Optional string. If set, the test will be skipped. The string+  SHOULD explain the reason for skipping the test (e.g. JIRA ticket).++.. _test_operations:++- ``operations``: Required array of one or more `operation`_ objects. List of+  operations to be executed for the test case.++.. _test_expectEvents:++- ``expectEvents``: Optional array of one or more `expectedEventsForClient`_+  objects. For one or more clients, a list of events that are expected to be+  observed in a particular order.++  If a driver only supports configuring event listeners globally (for all+  clients), the test runner SHOULD associate each observed event with a client in+  in order to perform these assertions.++  Test files SHOULD NOT expect events from multiple specs (e.g. command+  monitoring *and* SDAM events) for a single client. See+  `Mixing event types in observeEvents and expectEvents`_ for more+  information.++.. _test_outcome:++- ``outcome``: Optional array of documents. Each document will specify expected+  contents of a collection after all operations have been executed. The list of+  documents therein SHOULD be sorted ascendingly by the ``_id`` field to allow+  for deterministic comparisons.++  If set, the array should contain at least one document. The structure of each+  document is defined in `collectionData`_.+++operation+~~~~~~~~~++An operation to be executed as part of the test.++The structure of this object is as follows:++.. _operation_name:++- ``name``: Required string. Name of the operation (e.g. method) to perform on+  the object.++.. _operation_object:++- ``object``: Required string. Name of the object on which to perform the+  operation. This should correspond to either an `entity`_ name (for+  `Entity Test Operations`_) or "testRunner" (for `Special Test Operations`_).+  If the object is an entity, The YAML file SHOULD use an `alias node`_ for its+  ``id`` field (e.g. ``object: *collection0``).++.. _operation_arguments:++- ``arguments``: Optional object. Map of parameter names and values for the+  operation. The structure of this object will vary based on the operation.+  See `Entity Test Operations`_ and `Special Test Operations`_.++  The ``session`` parameter is handled specially (see `commonOptions_session`_).++.. _operation_expectError:++- ``expectError``: Optional `expectedError`_ object. One or more assertions for+  an error expected to be raised by the operation.++  This field is mutually exclusive with+  `expectResult <operation_expectResult_>`_ and+  `saveResultAsEntity <operation_saveResultAsEntity_>`_.++.. _operation_expectResult:++- ``expectResult``: Optional mixed type. A value corresponding to the expected+  result of the operation. This field may be a scalar value, a single document,+  or an array of documents in the case of a multi-document read.  Test runners+  MUST follow the rules in `Evaluating Matches`_ when processing this assertion.++  This field is mutually exclusive with `expectError <operation_expectError_>`_.++.. _operation_saveResultAsEntity:++- ``saveResultAsEntity``: Optional string. If specified, the actual result+  returned by the operation (if any) will be saved with this name in the+  `Entity Map`_.  The test runner MUST raise an error if the name is already in+  use. If the operation does not return a value (e.g. void method), the test+  runner MUST store an empty value (e.g. ``null``) for the entity such that the+  name will still be defined in the entity map.++  This field is mutually exclusive with `expectError <operation_expectError_>`_.++  This is primarily used for creating a `changeStream`_ entity from the result+  of a `client_createChangeStream`_, `database_createChangeStream`_, or+  `collection_createChangeStream`_ operation.+++expectedError+~~~~~~~~~~~~~++One or more assertions for an error/exception, which is expected to be raised by+an executed operation. At least one key is required in this object.++The structure of this object is as follows:++- ``isError``: Optional boolean. If true, the test runner MUST assert that an+  error was raised. This is primarily used when no other error assertions apply+  but the test still needs to assert an expected error. Test files MUST NOT+  specify false, as `expectedError`_ is only applicable when an operation is+  expected to raise an error.++- ``isClientError``: Optional boolean. If true, the test runner MUST assert that+  the error originates from the client (i.e. it is not derived from a server+  response). If false, the test runner MUST assert that the error does not+  originate from the client.++  Client errors include, but are not limited to: parameter validation errors+  before a command is sent to the server; network errors.++- ``errorContains``: Optional string. A substring of the expected error message+  (e.g. "errmsg" field in a server error document). The test runner MUST assert+  that the error message contains this string using a case-insensitive match.++  See `bulkWrite`_ for special considerations for BulkWriteExceptions.++- ``errorCode``: Optional integer. The expected "code" field in the+  server-generated error response. The test runner MUST assert that the error+  includes a server-generated response whose "code" field equals this value.+  In the interest of readability, YAML files SHOULD use a comment to note the+  corresponding code name (e.g. ``errorCode: 26 # NamespaceNotFound``).++  Server error codes are defined in+  `error_codes.yml <https://github.com/mongodb/mongo/blob/master/src/mongo/base/error_codes.yml>`__.++  Test files SHOULD NOT assert error codes for client errors, as specifications+  do not define standardized codes for client errors.++- ``errorCodeName``: Optional string. The expected "codeName" field in the+  server-generated error response. The test runner MUST assert that the error+  includes a server-generated response whose "codeName" field equals this value+  using a case-insensitive comparison.++  See `bulkWrite`_ for special considerations for BulkWriteExceptions.++  Server error codes are defined in+  `error_codes.yml <https://github.com/mongodb/mongo/blob/master/src/mongo/base/error_codes.yml>`__.++  Test files SHOULD NOT assert error codes for client errors, as specifications+  do not define standardized codes for client errors.++- ``errorLabelsContain``: Optional array of strings. A list of error label+  strings that the error is expected to have. The test runner MUST assert that+  the error contains all of the specified labels (e.g. using the+  ``hasErrorLabel`` method).++- ``errorLabelsOmit``: Optional array of strings. A list of error label strings+  that the error is expected not to have. The test runner MUST assert that+  the error does not contain any of the specified labels (e.g. using the+  ``hasErrorLabel`` method).++.. _expectedError_expectResult:++- ``expectResult``: Optional mixed type. This field follows the same rules as+  `operation.expectResult <operation_expectResult_>`_ and is only used in cases+  where the error includes a result (e.g. `bulkWrite`_). If specified, the test+  runner MUST assert that the error includes a result and that it matches this+  value.+++expectedEventsForClient+~~~~~~~~~~~~~~~~~~~~~~~++A list of events that are expected to be observed (in that order) for a client+while executing `operations <test_operations_>`_.++The structure of each object is as follows:++- ``client``: Required string. Client entity on which the events are expected+  to be observed. See `commonOptions_client`_.++- ``events``: Required array of `expectedEvent`_ objects. List of events, which+  are expected to be observed (in this order) on the corresponding client while+  executing `operations`_. If the array is empty, the test runner MUST assert+  that no events were observed on the client (excluding ignored events).+++expectedEvent+~~~~~~~~~~~~~++An event (e.g. APM), which is expected to be observed while executing the test's+operations.++This object MUST contain **exactly one** top-level key that identifies the+event type and maps to a nested object, which contains one or more assertions+for the event's properties.++The structure of this object is as follows:++.. _expectedEvent_commandStartedEvent:++- ``commandStartedEvent``: Optional object. Assertions for a one or more+  `CommandStartedEvent <../command-monitoring/command-monitoring.rst#api>`__+  fields.++  The structure of this object is as follows:++  - ``command``: Optional document. Test runners MUST follow the rules in+    `Evaluating Matches`_ when processing this assertion.++  - ``commandName``: Optional string. Test runners MUST assert that the actual+    command name matches this value using a case-insensitive comparison.++  - ``databaseName``: Optional string. Test runners MUST assert that the actual+    command name matches this value using a case-insensitive comparison. THe+    YAML file SHOULD use an `alias node`_ for this value (e.g.+    ``databaseName: *database0Name``).++.. _expectedEvent_commandSucceededEvent:++- ``commandSucceededEvent``: Optional object. Assertions for a one or more+  `CommandSucceededEvent <../command-monitoring/command-monitoring.rst#api>`__+  fields.++  The structure of this object is as follows:++  - ``reply``: Optional document. Test runners MUST follow the rules in+    `Evaluating Matches`_ when processing this assertion.++  - ``commandName``: Optional string. Test runners MUST assert that the actual+    command name matches this value using a case-insensitive comparison.++.. _expectedEvent_commandFailedEvent:++- ``commandFailedEvent``: Optional object. Assertions for a one or more+  `CommandFailedEvent <../command-monitoring/command-monitoring.rst#api>`__+  fields.++  The structure of this object is as follows:++  - ``commandName``: Optional string. Test runners MUST assert that the actual+    command name matches this value using a case-insensitive comparison.+++collectionOrDatabaseOptions+~~~~~~~~~~~~~~~~~~~~~~~~~~~++Map of parameters used to construct a collection or database object.++The structure of this object is as follows:++  - ``readConcern``: Optional object. See `commonOptions_readConcern`_.++  - ``readPreference``: Optional object. See `commonOptions_readPreference`_.++  - ``writeConcern``: Optional object. See `commonOptions_writeConcern`_.+++Common Options+--------------++This section defines the structure of common options that are referenced from+various contexts in the test format. Comprehensive documentation for some of+these types and their parameters may be found in the following specifications:++- `Read and Write Concern <../read-write-concern/read-write-concern.rst>`__.+- `Server Selection: Read Preference <../server-selection/server-selection.rst#read-preference>`__.++The structure of these common options is as follows:++.. _commonOptions_collectionName:++- ``collectionName``: String. Collection name. The YAML file SHOULD use an+  `alias node`_ for a collection entity's ``collectionName`` field (e.g.+  ``collectionName: *collection0Name``).++.. _commonOptions_databaseName:++- ``databaseName``: String. Database name. The YAML file SHOULD use an+  `alias node`_ for a database entity's ``databaseName`` field (e.g.+  ``databaseName: *database0Name``).++.. _commonOptions_readConcern:++- ``readConcern``: Object. Map of parameters to construct a read concern.++  The structure of this object is as follows:++  - ``level``: Required string.++.. _commonOptions_readPreference:++- ``readPreference``: Object. Map of parameters to construct a read+  preference.++  The structure of this object is as follows:++  - ``mode``: Required string.++  - ``tagSets``: Optional array of objects.++  - ``maxStalenessSeconds``: Optional integer.++  - ``hedge``: Optional object.++.. _commonOptions_client:++- ``client``: String. Client entity name, which the test runner MUST resolve+  to a MongoClient object. The YAML file SHOULD use an `alias node`_ for a+  client entity's ``id`` field (e.g. ``client: *client0``).++.. _commonOptions_session:++- ``session``: String. Session entity name, which the test runner MUST resolve+  to a ClientSession object. The YAML file SHOULD use an `alias node`_ for a+  session entity's ``id`` field (e.g. ``session: *session0``).++.. _commonOptions_writeConcern:++- ``writeConcern``: Object. Map of parameters to construct a write concern.++  The structure of this object is as follows:++  - ``journal``: Optional boolean.++  - ``w``: Optional integer or string.++  - ``wtimeoutMS``: Optional integer.+++Version String+--------------++Version strings, which are used for `schemaVersion`_ and `runOnRequirement`_,+MUST conform to one of the following formats, where each component is an+integer:++- ``<major>.<minor>.<patch>``+- ``<major>.<minor>`` (``<patch>`` is assumed to be zero)+- ``<major>`` (``<minor>`` and ``<patch>`` are assumed to be zero)+++Entity Test Operations+----------------------++Entity operations correspond to an API method on a driver object. If+`operation.object <operation_object_>`_ refers to an `entity`_ name (e.g.+"collection0") then `operation.name <operation_name_>`_ is expected to reference+an API method on that class.++Some specifications group optional parameters for API methods under an+``options`` parameter (e.g. ``options: Optional<UpdateOptions>`` in the CRUD+spec); however, driver APIs vary in how they accept options (e.g. Python's+keyword/named arguments, ``session`` as either an option or required parameter+depending on whether a language supports method overloading). Therefore, test+files SHALL declare all required and optional parameters for an API method+directly within `operation.arguments <operation_arguments_>`_ (e.g. ``upsert``+for ``updateOne`` is *not* nested under an ``options`` key).++If ``session`` is specified in `operation.arguments`_, it is defined according+to `commonOptions_session`_. Test runners MUST resolve the ``session`` argument+to `session <entity_session_>`_ entity *before* passing it as a parameter to any+API method.++If ``readConcern``, ``readPreference``, or ``writeConcern`` are specified in+`operation.arguments`_, test runners MUST interpret them according to the+corresponding definition in `Common Options`_ and MUST convert the value into+the appropriate object *before* passing it as a parameter to any API method.++This spec does not provide exhaustive documentation for all possible API methods+that may appear in a test; however, the following sections discuss all supported+entities and their operations in some level of detail. Special handling for+certain operations is also discussed below.++Test files SHALL use camelCase when referring to API methods and parameters,+even if the defining specifications use other forms (e.g. snake_case in GridFS).+++client+~~~~~~++These operations and their arguments may be documented in the following+specifications:++- `Change Streams <../change-streams/change-streams.rst>`__+- `Enumerating Databases <../enumerate-databases.rst>`__++Client operations that require special handling or are not documented by an+existing specification are described below.+++.. _client_createChangeStream:++createChangeStream+``````````````````++Creates a cluster-level change stream and ensures that the server-side cursor+has been created.++This operation proxies the client's ``watch`` method and supports the same+arguments and options. Test files SHOULD NOT use the client's ``watch``+operation directly for reasons discussed in `changeStream`_. Test runners MUST+ensure that the server-side cursor is created (i.e. ``aggregate`` is executed)+as part of this operation and before the resulting change stream might be saved+with `operation.saveResultAsEntity <operation_saveResultAsEntity_>`_.+++database+~~~~~~~~++These operations and their arguments may be documented in the following+specifications:++- `Change Streams <../change-streams/change-streams.rst>`__+- `CRUD <../crud/crud.rst>`__+- `Enumerating Collections <../enumerate-collections.rst>`__++Database operations that require special handling or are not documented by an+existing specification are described below.+++.. _database_createChangeStream:++createChangeStream+``````````````````++Creates a database-level change stream and ensures that the server-side cursor+has been created.++This operation proxies the database's ``watch`` method and supports the same+arguments and options. Test files SHOULD NOT use the database's ``watch``+operation directly for reasons discussed in `changeStream`_. Test runners MUST+ensure that the server-side cursor is created (i.e. ``aggregate`` is executed)+as part of this operation and before the resulting change stream might be saved+with `operation.saveResultAsEntity <operation_saveResultAsEntity_>`_.+++runCommand+``````````++Generic command runner.++This method does not inherit a read concern or write concern (per the+`Read and Write Concern <../read-write-concern/read-write-concern.rst#generic-command-method>`__+spec), nor does it inherit a read preference (per the+`Server Selection <../server-selection/server-selection.rst#use-of-read-preferences-with-commands>`__+spec); however, they may be specified as arguments.++The following arguments are supported:++- ``command``: Required document. The command to be executed.++- ``commandName``: Required string. The name of the command to run. This is used+  by languages that are unable preserve the order of keys in the ``command``+  argument when parsing YAML/JSON.++- ``readConcern``: Optional object. See `commonOptions_readConcern`_.++- ``readPreference``: Optional object. See `commonOptions_readPreference`_.++- ``session``: Optional string. See `commonOptions_session`_.++- ``writeConcern``: Optional object. See `commonOptions_writeConcern`_.+++collection+~~~~~~~~~~++These operations and their arguments may be documented in the following+specifications:++- `Change Streams <../change-streams/change-streams.rst>`__+- `CRUD <../crud/crud.rst>`__+- `Enumerating Indexes <../enumerate-indexes.rst>`__+- `Index Management <../index-management.rst>`__++Collection operations that require special handling or are not documented by an+existing specification are described below.+++.. _collection_createChangeStream:++createChangeStream+``````````````````++Creates a collection-level change stream and ensures that the server-side cursor+has been created.++This operation proxies the collection's ``watch`` method and supports the same+arguments and options. Test files SHOULD NOT use the collection's ``watch``+operation directly for reasons discussed in `changeStream`_. Test runners MUST+ensure that the server-side cursor is created (i.e. ``aggregate`` is executed)+as part of this operation and before the resulting change stream might be saved+with `operation.saveResultAsEntity <operation_saveResultAsEntity_>`_.+++bulkWrite+`````````++The ``requests`` parameter for ``bulkWrite`` is documented as a list of+WriteModel interfaces. Each WriteModel implementation (e.g. InsertOneModel)+provides important context to the method, but that type information is not+easily expressed in YAML and JSON. To account for this, test files MUST nest+each WriteModel object in a single-key object, where the key identifies the+request type (e.g. "insertOne"), as in the following example::++    arguments:+      requests:+        - insertOne:+            document: { _id: 1, x: 1 }+        - replaceOne:+            filter: { _id: 2 }+            replacement: { x: 2 }+            upsert: true+        - updateOne:+            filter: { _id: 3 }+            update: { $set: { x: 3 } }+            upsert: true+        - updateMany:+            filter: { }+            update: { $inc: { x: 1 } }+        - deleteOne:+            filter: { x: 2 }+        - deleteMany:+            filter: { x: { $gt: 2 } }+      ordered: true++While operations typically raise an error *or* return a result, the+``bulkWrite`` operation is unique in that it may report both via the+``writeResult`` property of a BulkWriteException. In this case, the intermediary+write result may be matched with `expectedError_expectResult`_. Because+``writeResult`` is optional for drivers to implement, such assertions should+utilize the `$$unsetOrMatches`_ operator.++Additionally, BulkWriteException is unique in that it aggregates one or more+server errors in its ``writeConcernError`` and ``writeErrors`` properties.+When test runners evaluate `expectedError`_ assertions for ``errorContains`` and+``errorCodeName``, they MUST examine the aggregated errors and consider any+match therein to satisfy the assertion(s). Drivers that concatenate all write+and write concern error messages into the BulkWriteException message MAY+optimize the check for ``errorContains`` by examining the concatenated message.+Drivers that expose ``code`` but not ``codeName`` through BulkWriteException MAY+translate the expected code name to a number (see:+`error_codes.yml <https://github.com/mongodb/mongo/blob/master/src/mongo/base/error_codes.yml>`__)+and compare with ``code`` instead, but MUST raise an error if the comparison+cannot be attempted (e.g. ``code`` is also not available, translation fails).+++session+~~~~~~~++These operations and their arguments may be documented in the following+specifications:++- `Convenient API for Transactions <../transactions-convenient-api/transactions-convenient-api.rst>`__+- `Driver Sessions <../sessions/driver-sessions.rst>`__++Session operations that require special handling or are not documented by an+existing specification are described below.+++withTransaction+```````````````++The ``withTransaction`` operation's ``callback`` parameter is a function and not+easily expressed in YAML/JSON. For ease of testing, this parameter is expressed+as an array of `operation`_ objects (analogous to+`test.operations <test_operations>`_). Test runners MUST evaluate error and+result assertions when executing these operations in the callback.+++bucket+~~~~~~++These operations and their arguments may be documented in the following+specifications:++- `GridFS <../gridfs/gridfs-spec.rst>`__++Bucket operations that require special handling or are not documented by an+existing specification are described below.+++.. _downloadToStream:+.. _downloadToStreamByName:++downloadToStream and downloadToStreamByName+```````````````````````````````````````````++These operations SHOULD NOT be used in test files. See+`IO operations for GridFS streams`_ in `Future Work`_.+++.. _openDownloadStream:+.. _openDownloadStreamByName:++openDownloadStream and openDownloadStreamByName+```````````````````````````````````````````````++The ``openDownloadStream`` and ``openDownloadStreamByName`` operations SHOULD+use `$$matchesHexBytes`_ in `expectResult <operation_expectResult_>`_ to match+the contents of the returned stream. These operations MAY use+`saveResultAsEntity <operation_saveResultAsEntity_>`_ to save the stream for use+with a subsequent operation (e.g. `uploadFromStream`_ ).+++.. _openUploadStream:+.. _openUploadStreamWithId:++openUploadStream and openUploadStreamWithId+```````````````````````````````````````````++These operations SHOULD NOT be used in test files. See+`IO operations for GridFS streams`_ in `Future Work`_. +++.. _uploadFromStream:+.. _uploadFromStreamWithId:++uploadFromStream and uploadFromStreamWithId+```````````````````````````````````````````++The ``uploadFromStream`` and ``uploadFromStreamWithId`` operations' ``stream``+parameter is a stream as defined in the `GridFS <../gridfs/gridfs-spec.rst>`__+spec and not easily expressed in YAML/JSON. This parameter is expressed as an+entity name, which the test runner MUST resolve to a `stream <entity_stream_>`_+entity *before* passing it as a parameter to the method. The YAML file SHOULD+use an `alias node`_ for a stream entity's ``id`` field+(e.g. ``stream: *stream0``).+++changeStream+~~~~~~~~~~~~++Change stream entities are special in that they are not defined in+`createEntities`_ but are instead created by using+`operation.saveResultAsEntity <operation_saveResultAsEntity_>`_ with a+`client_createChangeStream`_, `database_createChangeStream`_, or+`collection_createChangeStream`_ operation.++Test files SHOULD NOT use a ``watch`` operation to create a change stream, as+the implementation of that method may vary among drivers. For example, some+implementations of ``watch`` immediately execute ``aggregate`` and construct the+server-side cursor, while others may defer ``aggregate`` until the change stream+object is iterated.++The `Change Streams <../change-streams/change-streams.rst>`__ spec does not+define a consistent API for the ChangeStream class, since the mechanisms for+iteration and capturing a resume token may differ between synchronous and+asynchronous drivers. To account for this, this section explicitly defines the+supported operations for change stream entities.+++iterateUntilDocumentOrError+```````````````````````````++Iterates the change stream until either a single document is returned or an+error is raised.++If `expectResult <operation_expectResult_>`_ is specified, it SHOULD be a single+document.++`Iterating the Change Stream <../change-streams/tests#iterating-the-change-stream>`__+in the change stream spec cautions drivers that implement a blocking mode of+iteration (e.g. asynchronous drivers) not to iterate the change stream+unnecessarily, as doing so could cause the test runner to block indefinitely.+This should not be a concern for ``iterateUntilDocumentOrError`` as iteration+only continues until either a document or error is encountered.+++Special Test Operations

Thanks I think all the SDAM test changes would be additive.

jmikola

comment created time in 11 days

PullRequestReviewEvent

Pull request review commentmongodb/specifications

Add heartbeatFrequencyMS default value for retryable read/writes and transaction tests.

 Changelog :2019-02-13: Modify test format for 4.2 sharded transactions, including              "useMultipleMongoses", ``object: testRunner``, the              ``targetedFailPoint`` operation, and recoveryToken assertions.+:2020-06-12: Add the default value for heartbeatFrequencyMS.

Agreed.

DmitryLukyanov

comment created time in 11 days

Pull request review commentmongodb/specifications

Add heartbeatFrequencyMS default value for retryable read/writes and transaction tests.

 control the fail point's behavior. ``failCommand`` supports the following   blocked for. Required when blockConnection is true.   `New in mongod 4.3.4 <https://jira.mongodb.org/browse/SERVER-41070>`_. +Speeding Up Tests+=================++Drivers should set the default heartbeatFrequencyMS to 5ms in order to take into account the latest changes regarding streaming protocol. If a test has an explicit heartbeatFrequencyMS value, drivers should use the explicit value.

I think this text should state that drivers manually lower minHeartbeatFrequencyMS if possible and reduce heartbeatFrequencyMS to that same value -- with an exception if the test already has an explicit heartbeatFrequencyMS value. You can suggest 5ms for both if you wish.

Agreed. @DmitryLukyanov can you confirm that reducing both these values to 5ms does not cause any tests to fail?

DmitryLukyanov

comment created time in 11 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentajdavis/mongo-mockup-db

OSError: [WinError 10038] An operation was attempted on something that is not a socket

I think this was fixed in https://github.com/ajdavis/mongo-mockup-db/pull/35. Can you try installing from master?

pip install --upgrade https://github.com/ajdavis/mongo-mockup-db/archive/1b50472e3997b523a2712c4b2f659cee59d407d9.zip
brianminsk

comment created time in 11 days

issue commenteventlet/eventlet

eventlet is incompatible with dnspython 2.0.0rc1

perhaps we shoudl reopen #632 to track it seperatly otherwise i think commit 46fc185 is not a compete fix.

I agree. The ssl module still does not work with dnspython 2.0 even with the fix in https://github.com/eventlet/eventlet/pull/639:

$ pip install --upgrade https://github.com/jayvdb/eventlet/archive/dnspython2.zip
$ pip install dnspython==2.0
$ PYMONGO_MUST_CONNECT=1 python green_framework_test.py eventlet -s test.test_client_context
...
  File "/Users/shane/git/mongo-python-driver/pymongo/pool.py", line 1180, in connect
    sock = _configured_socket(self.address, self.opts)
  File "/Users/shane/git/mongo-python-driver/pymongo/pool.py", line 1002, in _configured_socket
    sock = ssl_context.wrap_socket(sock, server_hostname=host)
  File "/Users/shane/git/mongo-python-driver/venvPYTHON-1854/lib/python3.8/site-packages/eventlet/green/ssl.py", line 448, in wrap_socket
    return GreenSSLSocket(sock, *a, _context=self, **kw)
  File "/Users/shane/git/mongo-python-driver/venvPYTHON-1854/lib/python3.8/site-packages/eventlet/green/ssl.py", line 69, in __new__
    ret = _original_sslsocket._create(
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/ssl.py", line 1031, in _create
    self._sslobj = self._context._wrap_socket(
TypeError: _wrap_socket() argument 'sock' must be _socket.socket, not SSLSocket
...
frenzymadness

comment created time in 12 days

more