terraform

Commit Graph

Author	SHA1	Message	Date
Martin Atkins	170cca1332	stacks+promising: Better error messages for promise resolution failure We were previously just treating promising.ErrUnresolved as a singleton that doesn't carry any context along with it. This particular error always represents a bug in the stack runtime rather than a problem with the input, because resolving all of the promises is a key part of the contract for package promising, but it's still helpful to know a little more about what exactly has failed when debugging it. Therefore promising.ErrUnresolved is now a type rather than a value, and its carries with it a set of promise ids that were left unresolved. The stackeval package then recognizes this error type and uses its own records of what each promise was supposed to produce to hopefully return a useful error message that would narrow down what part of the system is buggy. Since this message always reflects a bug in Terraform the error message will probably just be copy-pasted into a bug report, and so this particular diagnostic type (unlike the one we use for promise self-references) only has one presentation form that we use regardless of how many promises we have to return.	2 years ago
Martin Atkins	b60aadd1ec	promising: Add HashiCorp copyright comments	3 years ago
Martin Atkins	a9f3ad5a68	promising: A new utility for concurrent, inter-dependent data lookups For the main Terraform language runtime we've traditionally used an explicit directed acyclic graph to manage the order of execution, which is effective and proven but leads to an unfortunate inversion-of-control programming style both for graph construction and graph walking that can be difficult to read and debug. For the stacks language runtime we're going to use a slightly different approach of writing some relatively normal-looking functions that each appear to be normal straight-through code but internally are running as collaborating goroutines. This should make the control flow and data flow somewhat clearer. An important building block for this is a way for these different functions to asynchronously provide data to one another without the risk of deadlock. This new package "promising" provides that by modeling a bipartite graph of tasks and promises, where each promise has a single task responsible for resolving it and each task has zero or one promises it's waiting for. If any task attempts a wait that would introduce a cycle into the graph then the get operation immediately fails to avoid a deadlock.	3 years ago

Author

SHA1

Message

Date

Martin Atkins

170cca1332

stacks+promising: Better error messages for promise resolution failure

We were previously just treating promising.ErrUnresolved as a singleton
that doesn't carry any context along with it. This particular error always
represents a bug in the stack runtime rather than a problem with the input,
because resolving all of the promises is a key part of the contract for
package promising, but it's still helpful to know a little more about what
exactly has failed when debugging it.

Therefore promising.ErrUnresolved is now a type rather than a value, and
its carries with it a set of promise ids that were left unresolved. The
stackeval package then recognizes this error type and uses its own records
of what each promise was supposed to produce to hopefully return a useful
error message that would narrow down what part of the system is buggy.

Since this message always reflects a bug in Terraform the error message
will probably just be copy-pasted into a bug report, and so this particular
diagnostic type (unlike the one we use for promise self-references) only
has one presentation form that we use regardless of how many promises
we have to return.

Martin Atkins

b60aadd1ec

promising: Add HashiCorp copyright comments

Martin Atkins

a9f3ad5a68

promising: A new utility for concurrent, inter-dependent data lookups

For the main Terraform language runtime we've traditionally used an
explicit directed acyclic graph to manage the order of execution, which
is effective and proven but leads to an unfortunate inversion-of-control
programming style both for graph construction and graph walking that can
be difficult to read and debug.

For the stacks language runtime we're going to use a slightly different
approach of writing some relatively normal-looking functions that each
appear to be normal straight-through code but internally are running
as collaborating goroutines. This should make the control flow and data
flow somewhat clearer.

An important building block for this is a way for these different
functions to asynchronously provide data to one another without the risk
of deadlock. This new package "promising" provides that by modeling a
bipartite graph of tasks and promises, where each promise has a single
task responsible for resolving it and each task has zero or one promises
it's waiting for. If any task attempts a wait that would introduce a
cycle into the graph then the get operation immediately fails to avoid
a deadlock.

3 Commits (sarah/init-cmd-testing-comments)