fix: inserting non-finite floats with insert_rows()

[plamut]

Fixes #696.

This PR fixes inserting Nan and non-finite floats with the client.insert_rows() method.

PR checklist:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

[plamut]

test_insert_rows_from_dataframe() fails, will investigate how the changes affected Nan-handling there.

[plamut]

I could not reproduce the failed test even after multiple trials, running it both in isolation and in the entire test suite. It seems weird why there would be no rows in the query results, NaN conversions didn't seem to play the role here.

        rows = list(
            bigquery_client.query(
                "SELECT * FROM `{}.{}.{}`".format(
                    table.project, table.dataset_id, table.table_id
                )
            )
        )

        sorted_rows = sorted(rows, key=operator.attrgetter("int_col"))
        row_tuples = [r.values() for r in sorted_rows]
        expected = [...]

>       assert len(row_tuples) == len(expected)
E       AssertionError: assert 0 == 6
E        +  where 0 = len([])
E        +  and   6 = len([(1.11, True, 'my string', 10), (2.22, False, 'another string', 20), (3.33, False, 'another string', 30), (4.44, True, 'another string', 40), (5.55, False, 'another string', 50), (6.66, True, None, 60)])

In any case, re-running the CI checks made them pass, and the same result was consistently reproduced locally.

[jimfulton]

I could not reproduce the failed test even after multiple trials, running it both in isolation and in the entire test suite. It seems weird why there would be no rows in the query results, NaN conversions didn't seem to play the role here.

        rows = list(
            bigquery_client.query(
                "SELECT * FROM `{}.{}.{}`".format(
                    table.project, table.dataset_id, table.table_id
                )
            )
        )

        sorted_rows = sorted(rows, key=operator.attrgetter("int_col"))
        row_tuples = [r.values() for r in sorted_rows]
        expected = [...]

>       assert len(row_tuples) == len(expected)
E       AssertionError: assert 0 == 6
E        +  where 0 = len([])
E        +  and   6 = len([(1.11, True, 'my string', 10), (2.22, False, 'another string', 20), (3.33, False, 'another string', 30), (4.44, True, 'another string', 40), (5.55, False, 'another string', 50), (6.66, True, None, 60)])

In any case, re-running the CI checks made them pass, and the same result was consistently reproduced locally.

That failed for me too yesterday. I'll create a flaky-test issue.

Eventual consistency?

[plamut]

@jimfulton Can't say, it's the first time I'm seeing this failure in 2+ years. Something on the backend might have changed related to when the streamed data is available. It should be as soon as after a few seconds, but even this might be too late in certain circumstances, just enough for the test to fail.

[tseaver]

@plamut, @jimfulton For the flaky test, the test_utils.retry.RetryResult wrapper might help. Something like:

from test_utils.retry import RetryResult

def _list_query(client, query):
    return list(client.query(query)

def _check_result(result, expected_length)
     return len(result) == expected_length

retry = RetryResult(functools.partial(_check_result, expected_length=len(expected))
retry(_list_query)(bigquery_client, query)