Skip to content

Conversation

@edsavage
Copy link
Contributor

Ensure that quantiles state documents are always removed after an error has been encountered. This is intended to stop the disk being cluttered with many such documents after repeated failures.

Ensure that quantiles state documents are always removed after an error has been encountered. This is intended to stop the disk being cluttered with many such documents after repeated failures.
@prodsecmachine
Copy link

prodsecmachine commented Jan 26, 2026

Snyk checks have passed. No issues have been found so far.

Status Scanner Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@edsavage edsavage requested a review from valeriy42 January 26, 2026 03:33
Copy link
Contributor

@valeriy42 valeriy42 left a comment

Choose a reason for hiding this comment

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

Thank you for addressing this issue. I have a couple of quick comments.

A more general comment: we have the same situation in bin/autodetect/Main.cc. Maybe you can generalize the RAII guard and use it in both cases.

isInputFileNamedPipe, outputFileName, isOutputFileNamedPipe, quantilesStateFile,
deleteStateFiles, writeCsv, validElasticLicenseKeyConfirmed);

if (!quantilesStateFile.empty()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If understand this correctly, since the RAII guard was created before the logger reconfiguration, if something will fail, the LOG_WARN message in Line 64 will be logged in stderr instead of the logging named pipe.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, any logging prior to the logger reconfiguration to use a named pipe as the sink will go to stderr. Which is unfortunate but not a disaster.

}
LOG_WARN(<< "Deleting quantiles state file '" << m_QuantilesStateFile << "'");
// Ignore the return value from remove, the file may have already been deleted.
std::remove(m_QuantilesStateFile.c_str());
Copy link
Contributor

Choose a reason for hiding this comment

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

You need to check the return value of std::remove and log if the files could not be deleted for some reason (permissions, locked file, etc.).

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, it would be consistent with the happy path behavior to delete the quantile files only when --deleteStateFiles is set.

// No need for a warning here so we reset the cleanup function and delete the file explicitly if requested.
removeQuantilesStateOnFailure.reset();
if (deleteStateFiles) {
std::remove(quantilesStateFile.c_str());
Copy link
Contributor

Choose a reason for hiding this comment

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

Here again, it would be good to check the return value of std::remove and log success or failure with errno.

@edsavage edsavage requested a review from valeriy42 January 28, 2026 01:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants