Errors block

[denis256]

Description

Implementation of errors block:

• add parsing of errors block from HCL
• handling of errors based on configuration
• added integration tests
• removed unused context fields for excludes
• added error documentation

errors {
    # Retry block for transient errors
    retry "retry_network" {
        retryable_errors = [".*Error: network timeout.*"]
        max_attempts = 3
        sleep_interval_sec = 5
    }

    # Ignore block for non-critical errors
    ignore "ignore_warnings" {
        ignorable_errors = [
            ".*Warning: non-critical issue.*"
        ]
        message = "Ignoring non-critical warnings"
    }
}

RFC: #3134

TODOs

Read the Gruntwork contribution guidelines.

• Update the docs.
• Run the relevant tests successfully, including pre-commit checks.
• Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
• Include release notes. If this PR is backward incompatible, include a migration guide.

Release Notes (draft)

Added / Removed / Updated [X].

Migration Guide

[levkohimins]

Suggested change

	// RetryConfig represents the configuration for retrying specific errors
	// RetryConfig represents the configuration for retrying specific errors.

strict-list complains about a comment without a dot at the end.

[levkohimins]

Suggested change

	time.Sleep(time.Duration(action.RetrySleepSecs) * time.Second)
	select {
	case <-time.After(time.Duration(action.RetrySleepSecs) * time.Second):
	// try again
	case <-ctx.Done():
	return errors.New(ctx.Err())
	}

Let's imagine that if an user sets RetrySleepSecs to say 60 seconds and RetryAttempts to 4 times and then wants to terminate the application by pressing ctrl-c, nothing will happen for 240 seconds. To prevent this, we need to listen to the context in case it was cancelled.

[yhakbar]

I think we should add a note here indicating what this does.

e.g.

Populating values into the `signals` attribute results in a JSON file named `error-signals.json` being emitted on failure. This file can be useful to inspect in CI/CD systems to determine what the recommended course of action is to address the failure.

In this example, an error has occurred, the author of the unit has signaled that it is safe to revert adjustments to this unit. A CI/CD system could have a standard process of finding all units with files named `error-signals.json`, then checkout the previous commit and apply those units in that state, reverting their updates.

[denis256]

Updated docs