Client hangs on concurrent task retrieval due to wrong metadata
Closed this issue · 0 comments
Description
When working in a concurrent environment, I encountered an issue where client-1 makes a request to client-2 to retrieve a task's details. At that very moment, client-2 had just finished downloading the task from another client-3, and the sizeScope parameter had the value Normal.
However, it appears that client-2 had not yet updated the task's corresponding metadata before responding to client-1. As a result, client-1 received default metadata values. For instance, contentLength was reported as -1.
This incorrect contentLength value causes client-1's download process to never reach a 'complete' state, effectively causing a hang in the download process for client-1.
Steps to Reproduce
Set up client-1 to request a task from client-2.
While client-2 is in the process of downloading the task from client-3, ensure that the download is completed but the metadata update is pending.
At this point, have client-1 receive the response from client-2 with the default metadata values (e.g., contentLength of -1).
Expected Behavior
client-1 should receive accurate task metadata, including a valid contentLength, allowing the download process to complete successfully.
support data
client-2 log
client-1 log
Actual Behavior
client-1 receives default metadata values, causing the download process to indefinitely hang as it awaits the correct contentLength.
Environment:
- Dragonfly version: v2.0.8
- OS: CentOS Linux release 8.2.2004 (Core)
- Kernel (e.g.
uname -a): 4.18.0-193.6.3.el8_2.v1.4.x86_6 - Others: