Ensure on_demand content finishes saving before request completes
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 598
- Forks
- 168
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 86
Description
Author: @gerrod3 (gerrod)
Redmine Issue: 8989, https://pulp.plan.io/issues/8989
With #8980 a race condition was found from a client requesting on_demand content and closing the connection after downloading the content before the artifact was finished being saved to the database. The fix in https://github.com/pulp/pulpcore/pull/1447 ensures that the async save task isn't canceled, but a race condition is still present if a client closes the connection before the save is complete and then requests the artifact from the database. They will see no artifact present despite the fact the artifact is still being saved. The timing for this race condition is pretty tight for most artifacts and probably won't be experienced in any normal workflows.
The solution to remove this race condition is to wait before sending the last_chunk for the StreamedResponse like this https://github.com/pulp/pulpcore/commit/cd76a36ae74f98bb19bebe29a0db3e0879010028. This change would require changes in other plugins that define their own Downloaders and it is possible this condition isn't prevalent enough to warrant the work.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the StreamedResponse handling and the Downloader implementations mentioned in the issue, then review commit cd76a36ae74f98bb19bebe29a0db3e0879010028. Check how pulpcore and other plugins handle the final last_chunk; done means a client cannot observe the artifact as missing after the download completes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100