Do not re-queue not recoverable requests

[ichekrygin]

As a general rule, we requeue every failed request. However, there are cases when failures are non-recoverable and require an update to the resource definition itself (which in turn will re-queue it)

For example: If the resource contains an invalid property value

"InvalidParameterValue: Invalid database identifier"

There is no point of re-queue-int this request since the property value will not fix itself.

[jbw976]

This issue is going to take some thought and likely be specific to each controller. i.e. identifying the specific errors that are not recoverable will be different for each cloud provider API call.

[negz]

I believe we can solve this somewhat systemically if crossplaneio/crossplane#593 is merged. If requeue logic becomes a function of the error returned by CRUD operations then we can assert whether an error is recoverable and have the Reconciler scaffold avoid dequeueing accordingly, i.e.:

type recoverable struct{ error }

func (r recoverable) Recoverable() {}

func Recoverable(err error) error { return recoverable{err} }

func IsRecoverable(err error) bool {
	_, recoverable := err.(interface {
		Recoverable()
	})
	return recoverable
}

https://play.golang.org/p/H5eJBA8fi8y

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.