Closed azat closed 1 year ago
Hey!
This makes sense in theory. Could you rebase in master so the tests rerun. Would appreciate a review from someone else, as I'm not super familiar with the lifetime cycle of the client
Rebased, but now it requires workflow approval
Base: 94.65% // Head: 94.70% // Increases project coverage by +0.04%
:tada:
Coverage data is based on head (
8b660fb
) compared to base (92b071d
). Patch coverage: 100.00% of modified lines in pull request are covered.:exclamation: Current head 8b660fb differs from pull request most recent head cd4a2b2. Consider uploading reports for the commit cd4a2b2 to get more accurate results
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Looks like all failures are unrelated, since the last error in the log is:
==> Uploading
.url https://codecov.io/
.query commit=d9a20a766ba942b5722ee36a1210e62fbb0ae9f8&branch=HEAD&package=py2.1.12
Gzipping contents..
Compressed contents to 18443 bytes
Pinging Codecov...
Error: Could not determine repo and owner
Tip: See all example repositories: https://github.com/codecov?query=example
.pkg: _exit> python /opt/hostedtoolcache/Python/3.10.9/x64/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta
py310-gevent-eventlet-sasl: FAIL code 1 (171.97=setup[19.90]+cmd[152.06] seconds)
codecov: OK (14.40=setup[13.73]+cmd[0.66] seconds)
evaluation failed :( (187.83 seconds)
Error: Process completed with exit code 255.
Yes you are right, we have some flaky tests...
So, any news/feedback on this one?
@azat can you check the "allow edits from maintainers" box? I can't rebase to merge w/o that... or you can simply rebase it yourself, up to you.
@jeffwidman I don't have Allow edits from mainters
box due to the github issues for pull requests from organizations, and I completely forgot about this, next time will keep it in mind (maybe will do this from my main account).
Thanks!
Gotcha, I didn't even realize that was a functionality gap as I always contribute from my personal GitHub... makes sense.
In case of AUTH_FAILED in the zk-loop thread it will call client._session_callback which will reset the queue.
However another thread can add to this queue CloseInstance event, and if the _session_callback() will be called after CloseInstance was added to the queue, then stop() will never return (and zk-loop will endlessly spin).
Here is how it looks like with addititional logging:
You can find details in this gist 1.