[SERVER-53599] Log collection name on invariant. Created: 06/Jan/21  Updated: 29/Oct/23  Resolved: 26/Feb/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.0.0

Type: Improvement Priority: Major - P3
Reporter: Luke Pearson Assignee: Bynn Lee
Resolution: Fixed Votes: 1
Labels: newgrad
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2021-03-08
Participants:

 Description   

While working on the WT_NOTFOUND issue encountered by a number of users recently we've been looking at one particular invariant:

{"t":\{"$date":"2020-10-05T22:25:46.854+00:00"},"s":"F",  "c":"-",        "id":23083,   "ctx":"conn503635","msg":"Invariant failure","attr":\{"expr":"ret","error":"UnknownError: -31803: WT_NOTFOUND: item not found","file":"src/mongo/db/storage/wiredtiger/wiredtiger_record_store.cpp","line":1600}}

This invariant has proven to be very useful however on a number of occasions we've wanted to figure out which collection was being operated on when this invariant was hit (and a few other bits of info).

As such I'd like this invariant and perhaps other to log more information. For this one in particular I'd say the following pieces of information would be helpful:

  • The collection name (i.e. the one the user set not the collection-blah.wt)
  • The key
  • The read timestamp

Open for feedback.



 Comments   
Comment by Githook User [ 26/Feb/21 ]

Author:

{'name': 'Bynn Lee', 'email': 'bynn.lee@mongodb.com', 'username': 'bynn'}

Message: SERVER-53599 Log collection name on invariant
Branch: master
https://github.com/mongodb/mongo/commit/8b9167a79df87ee0b0c5b761108cae6a1a232050

Comment by Geert Bosch [ 14/Jan/21 ]

You're right it's still here. That seems problematic in a way, as collection names can change, but we still need to be able to have concurrent access to the RecordStore and there is no mutex protecting this. Also the question on what the name of the collection associated with a recordstore is (if it's associated with a collection at all) depends on the timestamp. It was quite a bit of trouble for the lock-free reads project to remove the _ns objects all around,, and there were also bugs related to missing updates.

Comment by Luke Pearson [ 11/Jan/21 ]

For simplicity then, I'll update the ticket to just be logging of the collection name. While the read timestamp and key could be useful it feels use case specific.

Comment by Louis Williams [ 08/Jan/21 ]

The collection name is available as _ns.

Comment by Luke Pearson [ 07/Jan/21 ]

I thought that might be the case, would that then be the UUID of the collection? Can that be used to get the customers collection name eventually?

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