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

I could not reproduce thefailed 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 == 6E        +  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.

I could not reproduce thefailed 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 == 6E        +  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?

@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 afew seconds, but even this might be too late in certain circumstances, just enough for the test to fail.

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

fromtest_utils.retryimportRetryResultdef_list_query(client,query):returnlist(client.query(query)def_check_result(result,expected_length)returnlen(result)==expected_lengthretry=RetryResult(functools.partial(_check_result,expected_length=len(expected))retry(_list_query)(bigquery_client,query)