Skip to content

Clean up after #52 and #58#59

Merged
dfed merged 4 commits into
mainfrom
dfed--clean-up
Mar 15, 2022
Merged

Clean up after #52 and #58#59
dfed merged 4 commits into
mainfrom
dfed--clean-up

Conversation

@dfed

@dfed dfed commented Mar 11, 2022

Copy link
Copy Markdown
Owner

Wrapping up some good discussions from #52 and #58

// If the application crashes between writing this header and writing the next message data, we'll have only lost the messages we were about to delete.
// If `writer.offsetInFile == FileHeader.expectedEndOfHeaderInFile`, then crashing before we update the header would lead to this now-empty file being viewed as corrupted.
try header.updateOffsetInFileAtEndOfNewestMessage(to: writer.offsetInFile)
reader.offsetInFileAtEndOfNewestMessage = writer.offsetInFile

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We determined that these lines were duplicative – our header is always set to where the writer.offsetInFile is at this stage.

@@ -62,9 +62,6 @@ final class CacheReader {
case .emptyRead:
guard !previousReadWasEmpty else {
// If the previous read was also empty, then the file has been corrupted.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is still correct

// If the previous read was also empty, then the file has been corrupted.
// Two empty reads in a row means that offsetInFileAtEndOfNewestMessage is incorrect.
// This inconsistency is likely due to a crash occurring during a message write, between truncating the file and updating the header values to reflect that the file was truncated.
// This file is actually empty, despite what the header tells us.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've determined that our attribution of how the file got corrupted is incorrect. Since we don't know how this happened, we are deleting the explanation.

XCTAssertEqual(
UInt64(createFileHeader().asData.count),
FileHeader.expectedEndOfHeaderInFile)
}

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like a good test to have

@bachand bachand left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for cleaning up. Even though this PR wasn't marked ready for review I reviewed it since I believe it's done.

@dfed dfed marked this pull request as ready for review March 15, 2022 00:38
@dfed

dfed commented Mar 15, 2022

Copy link
Copy Markdown
Owner Author

Oops. Thanks for the review Michael: you were right that this PR was indeed done.

@dfed dfed merged commit cc069c1 into main Mar 15, 2022
@dfed dfed deleted the dfed--clean-up branch March 15, 2022 03:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants