-
Notifications
You must be signed in to change notification settings - Fork 98
chore(x-goog-request-id): commit testing scaffold #1366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(x-goog-request-id): commit testing scaffold #1366
Conversation
…affolding This change chops down the load of the large changes for x-goog-spanner-request-id. It depends on PR googleapis#1366 and should only be merged after that PR. Updates googleapis#1261 Requires PR googleapis#1366
…affolding This change chops down the load of the large changes for x-goog-spanner-request-id. It depends on PR googleapis#1366 and should only be merged after that PR. Updates googleapis#1261 Requires PR googleapis#1366
…affolding This change chops down the load of the large changes for x-goog-spanner-request-id. It depends on PR googleapis#1366 and should only be merged after that PR. Updates googleapis#1261 Requires PR googleapis#1366
eb2c3d2
to
129f662
Compare
@rahul2393 kindly help me re-run the bots for this PR. Thank you |
129f662
to
6f10a1f
Compare
This change commits the scaffolding for which testing will be used. This is a carve out of PRs googleapis#1264 and googleapis#1364, meant to make those changes lighter and much easier to review then merge. Updates googleapis#1261
… activation later
6f10a1f
to
7988ffa
Compare
@rahul2393 kindly help me with another bot run, I've ensured all tests are passing locally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (with one tiny nit)
There is one test failure, but I don't really see how that could be related to this change:
=================================== FAILURES ===================================
_________________ TestDbApi.test_execute_batch_dml_abort_retry _________________
self =
dbapi_database =
def test_execute_batch_dml_abort_retry(self, dbapi_database):
"""Test that when any execute batch dml failed with Abort exception,
then the retry succeeds with transaction having insert as well as query
type of statements along with batch dml statements."""
method_count_interceptor = dbapi_database._method_count_interceptor
method_count_interceptor.reset()
# called 3 times
self._insert_row(1)
# called 3 times
self._cursor.execute("SELECT * FROM contacts")
self._cursor.fetchall()
self._cursor.execute("start batch dml")
self._insert_row(2)
self._insert_row(3)
dbapi_database._method_abort_interceptor.set_method_to_abort(
EXECUTE_BATCH_DML_METHOD, self._conn, 2
)
# called 3 times
self._cursor.execute("run batch")
dbapi_database._method_abort_interceptor.reset()
self._conn.commit()
assert method_count_interceptor._counts[COMMIT_METHOD] == 1
assert method_count_interceptor._counts[EXECUTE_BATCH_DML_METHOD] == 3
> assert method_count_interceptor._counts[EXECUTE_STREAMING_SQL_METHOD] == 6
E assert 8 == 6
(And if it is related to this change, then I expect it only to be related to test code, and not to affect any production code)
@@ -78,6 +79,27 @@ def unavailable_status() -> _Status: | |||
return status | |||
|
|||
|
|||
# Creates an UNAVAILABLE status with the smallest possible retry delay. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: do we need both this method and the instance method above? If so, could we at least put the main bit of logic into one method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching that, turns out you had already committed that code to main. I've removed it.
yeah that test failure is bizarre and the code I committed doesn't really touch production code and we already tested AtomicCounter.increment() and .reset() so I can't see a way either that it could work. Must be a flake. Kindly please help me re-run the bots @olavloite and thank you very much for the code review and approval! |
@rahul2393 @olavloite @harshachinta kindly help me run the bots. |
…affolding This change chops down the load of the large changes for x-goog-spanner-request-id. It depends on PR googleapis#1366 and should only be merged after that PR. Updates googleapis#1261 Requires PR googleapis#1366
…affolding This change chops down the load of the large changes for x-goog-spanner-request-id. It depends on PR googleapis#1366 and should only be merged after that PR. Updates googleapis#1261 Requires PR googleapis#1366
…affolding This change chops down the load of the large changes for x-goog-spanner-request-id. It depends on PR googleapis#1366 and should only be merged after that PR. Updates googleapis#1261 Requires PR googleapis#1366
This change commits the scaffolding for which testing will be used. This is a carve out of PRs #1264 and #1364, meant to make those changes lighter and much easier to review then merge.
Updates #1261