allthingssecurity opened a new pull request, #28072: URL: https://github.com/apache/camel/pull/28072
# Description [CAMEL-25757](https://issues.apache.org/jira/browse/CAMEL-25757) With `resumeDownload=true` and a `localWorkDirectory`, an interrupted download leaves `<name>.inprogress` behind, and the next poll asks Azure Files for the rest of the file with `new ShareFileRange(existingSize)`. The SDK then sends `x-ms-range: bytes=<existingSize>-`, and the service answers a ranged Get File with 206 Partial Content (Azure Files REST reference, [Specifying the range header for FileREST operations](https://learn.microsoft.com/en-us/rest/api/storageservices/specifying-the-range-header-for-file-service-operations); the SDK's generated `FilesService.download` also declares 200 and 206 as its expected answers). `retrieveFileToFileInLocalWorkDirectory` only accepted 200, so: 1. the rest of the file was appended to the `.inprogress` file, but the retrieve reported failure; the file was not renamed and not routed; 2. on every later poll the range starts at the end of the file, the service answers 416, the download throws and the `.inprogress` file is kept. The file was never routed again until the `.inprogress` file was deleted by hand. This change accepts 206 as a successful answer for a download whose range starts after 0. Downloads without a range (no `.inprogress` file, `resumeDownload=false`, the download to the message body) still check for 200. Not changed: a `.inprogress` file that already holds the whole file (the JVM stopped after the last byte and before the rename) still gets 416 on the next poll. That needs a comparison with the remote size and is a separate case. Tests: - New `FilesOperationsResumeDownloadTest` (2 tests): the real `FilesOperations` and the real Azure SDK client, with an `HttpClient` that answers Get File like Azure Files (200 without a range, 206 for a range inside the file, 416 for a range at or after its end). `resumedDownloadIsCompletedAndRenamed` starts with 4 bytes of a 10-byte file in `hello.txt.inprogress`: the SDK asks for `bytes=4-`; without the fix `retrieveFile` returns `false` (`expected: <true> but was: <false>`), with the fix it returns `true` and the local work file holds the 10 bytes. `downloadWithoutPartialFileIsRetrieved` passes with and without the fix; it shows that a download without a range is unchanged. - camel-azure-files unit tests: 30 run, 0 failures (formatter and import sort run in the same build). - Not run: the integration tests (they need an Azure storage account). How it was found: a small Z3 model of the byte ranges of a resumed download over several polls showed that, with the 200-only check, the file is never routed after an interruption, for every file size and every interruption point. The test above reproduces this on the real component. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-azure-files, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
