capistrant opened a new pull request, #20002: URL: https://github.com/apache/druid/pull/20002
### Description Seems to trace back to https://github.com/apache/druid/pull/16481 where we made this multipart upload async. Before this change any failed part would indeed result in an exceptional event. Explicitly throw when RetryableS3OutputStream fails to complete a multipart upload and aborts the write to s3. Right now, if an error occurs during completion of the multipart upload, we log the failure for that part and abort the large upload (correct to avoid orphaning files) before quietly returning to caller implicitly indicating success. Problem is, downstream code will try and fail to consume the files that were supposed to be uploaded and fail due to the object not existing. This can result in a hard to troubleshoot error since the real problem was the failed upload with an error log buried somewhere else. A common presentation I have seen for this is MSQ compaction using durable storage. During the shuffle a multipart upload to durable storage has a part that fails and aborts the rest of the upload + logs an error. But it doesn't throw and something downstream tries to access what would have been written by this worker which results in a no such key error from s3 and a task failure. Once you dig in you see that the multipart failure happened and doomed the task to fail down the road. This proposal intends to explicitly throw and in this case cause the compaction worker to fail fast instead of leave a landmine for whoever comes to read the data that wasn't written later. #### Release note Fixes an issue when MSQ durable storage writes to s3 could fail but not immediately report their failure, causing downstream code to fail in a way that made troubleshooting root cause more difficult. <hr> ##### Key changed/added classes in this PR * `RetryableS3OutputStream` <hr> <!-- Check the items by putting "x" in the brackets for the done things. Not all of these items apply to every PR. Remove the items which are not done or not relevant to the PR. None of the items from the checklist below are strictly necessary, but it would be very helpful if you at least self-review the PR. --> This PR has: - [ ] been self-reviewed. - [ ] added documentation for new or modified features or behaviors. - [ ] a release note entry in the PR description. - [ ] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links. - [ ] added or updated version, license, or notice information in [licenses.yaml](https://github.com/apache/druid/blob/master/dev/license.md) - [ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader. - [ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for [code coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md) is met. - [ ] added integration tests. - [ ] been tested in a test Druid cluster. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
