While using --incremental flag we are getting error from API

[sahusury]

Description:

Hi Team,
I am facing below error while trying to access Spectacles API with --incremental flag.

There are 2 important points to be noted:

1. With –incremental flag it was able to identify the number of explores which are affected by the code changes as highlighted in below screen-print.
2. Spectacles ran few queries in the background, which were captured in the queries section in looker admin.

It seems like Spectacles is unable to understand the response from the looker API and show it in a readable manner.

Please have a look into it and let me know if anything is needed from my end.

[sahusury]

Hi Team, Do you have any update on this issue.

[sahusury]

I have tried many below tests for my instance and the code if they can cause this error, but I still see the same issue/error in every below case.

1. Tried with Python5 and 3.3
2. Explicitly used API 4.0
3. Tried running spectacles in GCP CLI
4. Tried without --incremental tag
5. Tried explicitly specifying --explore tag
6. Corrected all the SQL errors in my project and just introduced 1 basic SQL error by specifying wrong column name in dimension SQL.

In each case I get the same below error:

Can you provide any way out of it.

[DylanBaker]

Hi @sahusury - thanks for opening the ticket.

This error seems to be happening because we're getting an API response from Looker that doesn't match the format we expect. We have seen this occasionally with errored queries, but haven't been able to pin down the reason for it.

The way we have been able to resolve this with users in the past is by identifying the explore in question and fixing the issue, either at the LookML or SQL level.

When you see the queries in the Looker UI, do you see any errors?
Would you be able to run this command but with subsets of the explores to try to identify which the issue is?
Are there any LookML issues in production in this project?

[DylanBaker]

Oh sorry - I've just re-read and noticed that you've mentioned that this is caused by an intentional error you've introduced. Is that correct?

If so, would you mind sharing the LookML of the error you introduced? Could you also please try running the dimension in the Looker UI and show me what the error there looks like?

Thanks!

[sahusury]

We intentionally introduced an error in the LookML dimension named id by pointing it to a non-existent column test in the database table. In this scenario, we expect Spectacles to catch the error and include the problematic field in its response.

Below is the error from explore:

Note: There are no other errors present in the LookML.

Since we are integrating Spectacles checks during Pull Request creation or merge, the goal is to ensure that when a SQL error occurs, the developer can identify and resolve it without manually searching through Looker Admin queries or lookml. This integration is meant to eliminate that manual effort.

Could you check why is the spectacles sql check breaking and how can this be resolved.

[DylanBaker]

@sahusury - I'm working on a PR to hopefully resolve this. You can track here: #861

[DylanBaker]

@sahusury - could you please try the latest release? 2.4.14

[sahusury]

@DylanBaker I tried with Spectacles 2.4.14 but I am still facing the same issue.

Approach 1: Tried in looker IDE with pull request

Approach 2: Tried in Google cloud shell

Please let me know if I should follow any other steps.

[DylanBaker]

Could you please run these with the verbose flag -v and share the API response that is logged out? I'd like to see where this doesn't match the schema. Thanks!

[sahusury]

Hi @DylanBaker
I tried with verbose mode and below is the error which I am facing:

The API was able to capture the error but not able to show it in proper manner and API broke with the below error:

[DylanBaker]

Thanks @sahusury. Looks like the SQL string isn't in the response, which we expected it to be. I've just pushed a new patch (2.4.15). Could you please try that?

[sahusury]

Hi @DylanBaker

I tried with the latest version and there are 2 observations:

1. SQL validation is taking very long time around 27mins to complete the validation for just 4 explores with incremental flag. How can we lower this time ?
2. The error shown in the output of validation is providing wrong lookml file name in which sql error is added.
   Note: I have added the error in Sbu_hfm file and its giving me error in account_hfmv file

[DylanBaker]

Hi @sahusury. Would you mind please running this with the verbose -v flag? I'll need the logs to understand why the runtime is long.

It also looks like there might be a bug in the end of run printout. I'll look into that.

[sahusury]

Hi @DylanBaker

With verbose mode enabled I received below error:

[DylanBaker]

Ah - apologies. That was an oversight on my end. Could you please try 2.4.18?