create_query_task triggers ":: NoMethodError : undefined method `scan' for 1:Fixnum"

@joeldodge79 We have been dealing with your support team who recommended filing a bug report against the Python SDK. We are dealing with a bug specific to our project, though it may impact others. I have done my best to strip out proprietary details and just relevant information. Please let me know if you need more information; I may have to provide that to you in a non public forum.

Python Version

3.7.5

SDK Version

looker-sdk==0.1.3b20

Description

For some queries, create_query_task return a successful task. For others, it returns a generic error:

Traceback (most recent call last):
  File "app/run.py", line 33, in <module>
    run()
  File "app/run.py", line 26, in run
    query_id=query.id, result_format="json"
  File "/Users/michaelcranston/src/looker/venv/lib/python3.7/site-packages/looker_sdk/sdk/api31/methods.py", line 5439, in create_query_task
    transport_options=transport_options,
  File "/Users/michaelcranston/src/looker/venv/lib/python3.7/site-packages/looker_sdk/rtl/api_methods.py", line 184, in post
    return self._return(response, structure)
  File "/Users/michaelcranston/src/looker/venv/lib/python3.7/site-packages/looker_sdk/rtl/api_methods.py", line 88, in _return
    raise error.SDKError(response.value.decode(encoding=encoding))

We also witness this Ruby exception in the Looker dashboard:

:: NoMethodError : undefined method `scan' for 1:Fixnum

Offending query

The following query triggers the error:

query = sdk.create_query(
    body=looker_sdk.models.WriteQuery(
        fields=[
            "performance_agg.account_id",
            "performance_agg.impression",
        ],
        view="performance_agg",
        filters={
            "performance_agg.account_id_filter": "1",
        },
        model="performance_agg",
    )
)
query_task = sdk.create_query_task(
    body=looker_sdk.models.WriteCreateQueryTask(
        query_id=query.id, result_format="json"
    )
)

Notes

• account_id_filter can be an integer or a string and it will have no affect
• changing the account_id_filter to another account (e.g. 12) will allow the query to succeed
• account_id_filter is defined as follows with actual field names replaced with foo_bar:

  filter: account_id_filter {
    type: number
    default_value: "{{ _user_attributes['foo_bar'] }}"
    required_access_grants: [foo_bar_123]
    sql: {% condition %} ${foo_bar} {% endcondition %} AND 2 = 2 ;;
  }

[tdaelemans]

On your explore set “sql_always_where: 1=1 ;;”

On Wed, May 19, 2021 at 1:20 PM Alex Silva @.***> wrote:

do you mind sharing a code sample for how you appended 1=1 to the query?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/looker-open-source/sdk-codegen/issues/385#issuecomment-844308922, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLIKHV3WYASZGRAONZ6INTTOPXORANCNFSM4T3WU5KQ .

[tdaelemans]

@ags2121 No, we ended up coding defensively around the issue in our application (always cast the offending field to a string so the query that is cached couldn’t be broken). The previously cached queries were/are still broken, but I busted the cache by appending 1=1 to every query task after we caught this issue so technically a new query was created/stored in the Looker system. This means between the validation and the 1=1 appending all new queries are valid and avoid the bugged state.