Skip to content
This repository has been archived by the owner on Aug 12, 2022. It is now read-only.

Fix "error: no errors" #312

Open
shimonp21 opened this issue Jun 3, 2022 · 5 comments
Open

Fix "error: no errors" #312

shimonp21 opened this issue Jun 3, 2022 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@shimonp21
Copy link
Contributor

Describe the bug

An interesting bug that stems from the fact that diag.Diagnostics implements the error interface (i.e. func Error() string {:
both diag.BaseError and diag.Diagnostics (i.e. a slice of diagnostics []diag.Diagnostics ) implement the error interface:

type error interface {
	Error() string
}

This means that, if a function returns diag.Diagnostics , but thinks it returns an error, it will be implicitly converted. And thus, even though the function returned nil, the caller will actually see error: no errors.
To reproduce:

func Test_DiagAndErrors(t *testing.T) {
	var err error

	err = functionReturningDiags0()
	if err != nil {
		fmt.Printf("error: %vֿ\n", err)
	}

	err = functionReturningDiagsNil()
	if err != nil {
		fmt.Printf("error: %vֿ\n", err)
	}
}

func functionReturningDiagsNil() diag.Diagnostics {
	return nil
}

func functionReturningDiags0() diag.Diagnostics {
	return diag.Diagnostics{}
}

Output:

error: no errorsֿ
error: no errorsֿ

Insights:
A customer complained about error: no errors in discord a couple of weeks ago (in relation to policies).
implicit conversion is bad! The code for converting Diagnostics to errors makes me believe that this is a side effect that the writer did not intend.

func (diags Diagnostics) Error() string {

My proposal would be to rename Diagnostics.Error() to Diagnostics.ToError() to avoid implementing the error interface and allowing this implicit conversion.

Expected Behavior

Steps to Reproduce

Possible Solution

No response

Provider and CloudQuery version

0.24.7

Additional Context

No response

@shimonp21
Copy link
Contributor Author

Summary of meeting today:

@shimonp21
Copy link
Contributor Author

The issue from cloudquery/cloudquery#772 was already fixed.

@shimonp21
Copy link
Contributor Author

Also, the single "Diag" might also not want to support the error interface.

looking at the code of our aws and GCP providers, I see only 1 place where we actually return a diagnostic and not an error from a resolver.

@shimonp21 shimonp21 self-assigned this Jun 22, 2022
@shimonp21
Copy link
Contributor Author

Sub issue (not huge priority):

column resolvers don't always mention which resource failed.

Resource: ec2.vpcs   Type: Access Severity: Warning
        Summary: column resolver "tags" failed for table "aws_ec2_vpcs": shimon is not authorized to perform something
        Resource ID: 615713231484,eu-west-3
        Detail: Something is wrong with your credentials. Ensure you have access to the specified resource.

I believe that this is because we don't resolve the PKs first...

@shimonp21
Copy link
Contributor Author

Moving to icebox per @yevgenypats request

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant