[SERVER-43325] Not all exceptions inside collection validation should result in {valid: false} Created: 13/Sep/19  Updated: 22/Aug/23

Status: Backlog
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-80177 validate() should not return valid:fa... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

The entire collection validation code block is wrapped inside of a `try catch` block.
Inside the `try block`, we treat all exceptions as a validation failure. But that isn't always the case. An exception can be thrown if we can't open a checkpoint cursor, if we're trying to open a checkpoint cursor while WiredTiger is running with LSM, etc. These shouldn't be treated as data corrupting failures.



 Comments   
Comment by Gregory Wlodarek [ 02/Apr/20 ]

I think catching exceptions in the outermost level of validate shouldn't be automatically treated as corruption being detected as that may not always be the case.

I'd be okay with simply returning {ok: 0} in these cases, but that still leaves the question of what should the valid field be set to. Perhaps omitting the valid field, in these cases, is fine.

Comment by Connie Chen [ 02/Apr/20 ]

gregory.wlodarek Is this still a problem?

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