Open seaneganx opened 2 years ago
435 addresses the functional issue of controlling worker pool execution.
Right, I remembered the discussion and forgot it was tracked.
Let's consider putting worker pool support (with some or all of these improvements) in a new package under /pkg
.
Background
The registry tool makes heavy use of the worker pool for concurrent execution of subtasks associated with various commands. Currently if a task returns an error, the worker pool will terminate the command entirely. Some tasks intentionally avoid returning errors to prevent this.
Typically commands will define a specialized struct that implements the Task interface and generate instances of these tasks to handle operations like uploading OpenAPI specs, uploading Discovery specs, uploading Protobuf specs, uploading specs from a CSV row, uploading specs with new annotations, or uploading specs with new labels. Commands that work with a variety of resource types often define one task per resource type, e.g. annotating APIs, annotating API Versions, and annotating API Specs. In other cases tasks are used for computation, executing external applications, and more.
When commands are generating tasks for the worker pool, they're often produced from resources in the registry or from files in one or more directories. When several resource types from the registry are permitted, commands usually determine the argument's resource type before fetching those resources.
Ideas