[SERVER-51473] Check return value from SeekableRecordCursor::restore() in various stages Created: 09/Oct/20  Updated: 23/Oct/20  Resolved: 23/Oct/20

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

Type: Task Priority: Major - P3
Reporter: Eric Cox (Inactive) Assignee: Eric Cox (Inactive)
Resolution: Won't Fix Votes: 0
Labels: qexec-team, quick-tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-50838 Coverity analysis defect 115741: Unch... Closed
Sprint: Query 2020-11-02
Participants:

 Description   

When investigating a coverity ticket for an unchecked return value in SERVER-50838 it was noticed that the return value was unchecked in 

  • CountScan::doRestoreStateRequiresIndex()
  • DistinctScan::doRestoreStateRequiresIndex()
  • sbe::IndexScanStage::doRestoreState()
  • SortedDataInterfaceThrottleCursor::restore()

Should we add uasserts to check the return values for these calls? We do check the return value in FetchStage.

uassert(50982"could not restore cursor for FETCH stage", couldRestore)



 Comments   
Comment by Eric Cox (Inactive) [ 23/Oct/20 ]

I took a look at each of the restore calls in the stages listed in the description. This ticket is a noop since the SortedDataInterface::Cursor is used instead of  SeekableRecordCursor::restore().

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