[SERVER-19014] RecordStore->restore() return value is often unused Created: 17/Jun/15  Updated: 30/Jul/18  Resolved: 30/Jul/18

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

Type: Improvement Priority: Trivial - P5
Reporter: Kyle Erf Assignee: Audrey Fang (Inactive)
Resolution: Done Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Storage NYC 2018-07-02, Storage NYC 2018-07-16, Storage NYC 2018-07-30, Storage NYC 2018-08-13
Participants:

 Description   

Coverity is complaining about multiple places in our code where we do not check the return value of RecordStore.restore()

        /**
         * Recovers from potential state changes in underlying data.
         *
         * Returns false if it is invalid to continue using this iterator. This usually means that
         * capped deletes have caught up to the position of this iterator and continuing could
         * result in missed data.
         *
         * If the former position no longer exists, but it is safe to continue iterating, the
         * following call to next() will return the next closest position in the direction of the
         * scan, if any.
         *
         * This handles restoring after either savePositioned() or saveUnpositioned().
         */
        virtual bool restore(OperationContext* txn) = 0;

It looks like all of the cases where we do this are safe and do not need to deal with the capped collections edge case. However, this is probably an indication that the API for RecordStore could be improved--it's a bit odd to have a return value that we throw away most of the time.



 Comments   
Comment by Eric Milkie [ 30/Jul/18 ]

Audrey pointed out to me that the code has changed a lot in 3 years and this function no longer has callers that ignore the return value. Some callers are indeed making use of the return value, so we decided not to change anything here.

Generated at Thu Feb 08 03:49:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.