Repository navigation
feat(concurrent): runners own their connection, connect timeout, singleton via runner - #129
Closed
greenhat616 wants to merge 4 commits into
Closed
greenhat616 wants to merge 4 commits into
greenhat616 wants to merge 4 commits into
Conversation
`TaskRunnerBuilder::connector` takes a `StreamConnector` that the runner awaits itself, while still applying cancellation and limits in that order. `Started` now means the runner is connected; a failed or cancelled connection reports only `Stopped`. Limits received while connecting shorten the delivery: the range requested from the server is already fixed.
The spawner connected each range inside the spawned task and handed the runner's channels back over a oneshot, collected by a separate pending group. It now spawns a runner given the range connector and returns the runner's receivers at once; a rejected spawn is queued and reported by the next tick. The manager learns that a runner connected from `Started`: - a stop before `Started` is a connect failure, which releases the range and never completes the chunk, even for `ExceededTotalSize`; - a lifecycle that closes before `Started` is sampled as a lost connect; - the data of a connecting runner is polled only after its `Started`, so it cannot overtake it between the two polls. The manager polls lifecycle before data, without the pending source, and a runner releases an abandoned connection before reporting its stop.
…unners A range runner that is not connected `TaskOptions::connect_timeout` (30 s by default) after it started connecting now fails with the retryable `Timeout` and its range is retried. Before, only the task-wide no-progress deadline bounded a connect, which other runners' progress kept pushing back. The timeout is not extended by limits; the runner traces how long it waited to be polled and how long it took to connect. The strategy's `SplitAllTask` now only splits running runners, like `SplitGivenTask` already did: a connecting runner has requested its whole range anyway.
The singleton task connected the full stream itself, bounded by the no-progress deadline, and then built a runner on it. It now hands the runner a connector and creates the temporary file once the runner reports `Started`; the runner waits for the file before streaming, so neither its idle nor its drain timeout runs during file setup, and the first speed sample starts there too. A connect blocked for `TaskOptions::connect_timeout` (30 s by default) now fails the singleton task with the retryable `TaskError::Timeout` instead of `NoProgress` after `no_progress_timeout`. A failed connection still reports `TaskInstanceError::StreamFailed` with the adapter's error.
Owner
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 5/6. Stacked on part 4.
TaskRunnerBuilder::connector: the runner connects its own stream;Startedmeans connected; a failed or cancelled connect reports onlyStopped.PendingRunnerGroupand its oneshot are gone; a stop beforeStartedis a connect failure and never completes a chunk; a connecting runner's data is polled only after itsStarted.TaskOptions::connect_timeout(30 s): a hung connect times out even while other runners progress;SplitAllTasknever splits connecting runners.Timeoutafterconnect_timeoutinstead ofNoProgressafterno_progress_timeout.