WEBVTT 00:00:00.700 --> 00:00:03.239 We already know how to call one endpoint. 00:00:03.389 --> 00:00:09.191 Now we will check three endpoints and produce one report, including a deliberate failure. 00:00:09.341 --> 00:00:13.907 A sequential loop would wait for each request before starting the next. 00:00:14.057 --> 00:00:20.919 Parallel lets several independent operations make progress at once, while an explicit worker limit keeps 00:00:20.919 --> 00:00:22.291 the workload bounded. 00:00:22.441 --> 00:00:30.353 We will use two workers, keep each result associated with its URL, and treat one failed request as a 00:00:30.353 --> 00:00:33.684 report entry instead of losing the entire batch. 00:00:35.830 --> 00:00:39.841 The input is an ordinary list of three local URLs. 00:00:39.991 --> 00:00:44.257 Start the included fixture exactly as in the previous lesson. 00:00:44.407 --> 00:00:49.058 These small values describe the work without opening any connection yet. 00:00:49.208 --> 00:00:56.824 That separation is useful: you can inspect the batch before sending it, add another URL, or remove a 00:00:56.824 --> 00:00:59.363 route without changing the worker logic. 00:00:59.513 --> 00:01:07.877 A more realistic service record could also contain a display name, but the URL alone is enough for this 00:01:07.877 --> 00:01:09.198 first reproducible example. 00:01:11.350 --> 00:01:16.257 Convert the list to a Stream, then pass it through parallel with a limit of two. 00:01:16.407 --> 00:01:20.588 Each worker receives one URL and returns one result. 00:01:20.738 --> 00:01:27.426 The documentation describes isolated workers and bounded buffers, so the concurrency setting is a 00:01:27.426 --> 00:01:31.725 resource decision, not a promise of a particular speedup. 00:01:31.875 --> 00:01:36.035 A larger number can increase pressure on your machine or the server. 00:01:36.185 --> 00:01:42.350 Begin with a modest limit and choose it according to the work and the service you are allowed to call. 00:01:44.500 --> 00:01:48.959 Inside the worker, attempt wraps the request and JSON decoding. 00:01:49.109 --> 00:01:54.677 It returns a result whose okay field tells us whether that operation succeeded. 00:01:54.827 --> 00:02:00.395 We then return a plain object containing the original URL and this Boolean. 00:02:00.545 --> 00:02:02.038 This placement matters. 00:02:02.188 --> 00:02:09.468 The recovery boundary belongs around each independent operation, so the missing route becomes one false 00:02:09.468 --> 00:02:09.953 value. 00:02:10.103 --> 00:02:17.296 If we let that error escape instead, the documented fail fast behavior would cancel the remaining work 00:02:17.296 --> 00:02:20.258 rather than produce a complete service report. 00:02:22.410 --> 00:02:26.271 After the worker block, collect consumes the finite batch. 00:02:26.421 --> 00:02:31.349 JSON encoding produces a report that other programs can read. 00:02:31.499 --> 00:02:36.534 Parallel preserves input order even if requests finish in a different order. 00:02:36.684 --> 00:02:43.809 That makes the output predictable, but it also means a slow early request can delay seeing later results. 00:02:43.959 --> 00:02:49.485 Do not interpret the order of report rows as the order of network completion. 00:02:49.635 --> 00:02:57.123 Each row still includes its URL, so it remains meaningful even if you later sort or filter the report. 00:02:59.270 --> 00:03:05.051 A common mistake is trying to accumulate a shared mutable total inside the workers. 00:03:05.201 --> 00:03:09.468 Run the supplied counter demonstration and inspect its result. 00:03:09.618 --> 00:03:15.698 On the validated local build, it returns one and two, rather than a running shared total. 00:03:15.848 --> 00:03:21.907 This demonstrates isolated behavior on the validated build, rather than a shared counter. 00:03:22.057 --> 00:03:30.407 Capture diagnostics can differ across engines and versions, so we will not rely on this mistake as an API 00:03:30.407 --> 00:03:30.846 contract. 00:03:30.996 --> 00:03:37.995 Return a value from each worker, then aggregate those returned values in the parent pipeline where the 00:03:37.995 --> 00:03:39.231 ownership is clear. 00:03:41.380 --> 00:03:44.516 Run the health checker while the fixture is available. 00:03:44.666 --> 00:03:49.637 The first and third routes succeed, and the intentionally missing route is false. 00:03:49.787 --> 00:03:52.453 Now stop the fixture and run it again. 00:03:52.603 --> 00:03:59.451 Requests should fail within their configured limits, and the report should still contain entries because 00:03:59.451 --> 00:04:01.734 attempt handles each request failure. 00:04:01.884 --> 00:04:08.859 This is a useful distinction between an operational problem and a broken script: the script can complete 00:04:08.859 --> 00:04:14.193 its reporting job while honestly recording that the services could not be reached. 00:04:16.340 --> 00:04:22.207 Extend each input from a URL to an object with a service name and URL. 00:04:22.357 --> 00:04:28.501 Update the worker to request the URL field and retain the name in its returned report. 00:04:28.651 --> 00:04:32.853 Then compare worker limits of one and two using the same input. 00:04:33.003 --> 00:04:40.570 Focus first on identical results rather than timing claims, because this tiny fixture is not a 00:04:40.570 --> 00:04:41.515 performance benchmark. 00:04:41.665 --> 00:04:49.273 You now have a repeatable concurrency pattern: finite input, bounded workers, local recovery, returned 00:04:49.273 --> 00:04:51.991 values, and one terminal collection.