[CDRIVER-3328] Provide a way to access the URI updated with TXT records from a mongoc_client_t Created: 21/Aug/19  Updated: 27/Oct/23  Resolved: 14/Jan/20

Status: Closed
Project: C Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kaitlin Mahar Assignee: Kevin Albertson
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt Dependency
Related
is related to CDRIVER-2425 authSource option from TXT record ign... Closed

 Description   

When a user uses creates a mongoc_client_t via a URI that specifies values via TXT record, the URI stored on the mongoc_client_t is not updated according to the records – per this line in the DNS tests it appears only the topology's copy is.

Since the topology is not publicly accessible, this makes it impossible for the Swift driver to e.g. get an accurate picture of the options set on a URI or to fully implement the initial DNS seedlist discovery spec tests.



 Comments   
Comment by Githook User [ 14/Jan/20 ]

Author:

{'name': 'Kevin Albertson', 'email': 'kevin.albertson@mongodb.com', 'username': 'kevinAlbs'}

Message: CDRIVER-3328 fixup DNS test
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/a59aec4acf349c3785dc6050ceda4b93be86d976

Comment by Kaitlin Mahar [ 10/Jan/20 ]

kevin.albertson Testing this out, I do see values that are only provided via TXT are showing up when I call the corresponding getters on the URI. I thought I had actually tested that before to confirm they did not show up, but apparently not. Thanks for looking into this!

Comment by Kevin Albertson [ 10/Jan/20 ]

kaitlin.mahar Looking into this, it appears the uri stored on the mongoc_client_t actually is updated after initial seedlist discovery (though it won't be updated during SRV polling, it should still get the new hosts and options from the initial SRV + TXT requests when constructing a client). The change in CDRIVER-2425 seem to have intended that behavior.

The comment in the DNS tests seems to be outdated. I'll update that test shortly. But otherwise, I believe there is no required change here. But let me know if I'm missing something.

Comment by Kaitlin Mahar [ 25/Aug/19 ]

That would work fine for our purposes. 

Comment by Jeremy Mikola [ 23/Aug/19 ]

Is there a particular reason to keep the client's URI separate from the topology?

In lieu of introducing a new API, I wonder if we could instead have mongoc_client_get_uri delegate to the topology (assuming that's always the most up-to-date struct). Is there value in preserving the original URI used to construct the client? If users needed a copy of that, I suppose they could fetch it immediately after creating/popping a client and copy it before it might be updated by SRV polling at a later point.

Comment by Kaitlin Mahar [ 22/Aug/19 ]

Implementing these tests is the first time we've run into a need for this.

That said, In the future we may provide a similar API to mongoc and allow a user to retrieve a MongoClient 's originating ConnectionString.
As a mongoc user, I found it surprising that retrieving a client's URI and looking up a property on that URI (e.g. replset) could give me a value that is actually incorrect for the client. Without a way to access the resolved URI, we have no choice but to provide that same possibly surprising behavior.
We also have SWIFT-501 open about rationalizing which options taken precedence when they are provided in both an options struct and a URI. If there is overlap between options that can be provided via TXT record and via our ClientOptions, that ticket may not be possible to complete if we can't tell which options are actually set in a URI.

Regarding the tests, In general, I believe it's beneficial for us to implement spec tests that check behavior encapsulated within mongoc. We've discovered mongoc bugs in the past via our runners that test mongoc logic. For example, change stream resumability is handled by mongoc, but implementing tests for that found CDRIVER-3329. I also recall that CDRIVER-2621 (issues with the read concern / write concern URI spec tests) was caught by our test runner.

Comment by Kevin Albertson [ 22/Aug/19 ]

Is this only necessary to implement tests in Swift? I don't know if we've added public API only for the sake of making test assertions for wrapper drivers. Since resolution of SRV/TXT records is contained in libmongoc, perhaps wrapping drivers should not be required to implement these tests?

Generated at Wed Feb 07 21:17:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.