MagicStack / MagicStack/asyncpg

Test failure in test_executemany_server_failure_during_writes

未关闭
#1,099 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

主要语言
Python
星标
8.1k
派生
468
PR 合并指标
30 天内没有已合并 PR

描述

* **asyncpg version**: 0.29.0
* **PostgreSQL version**: 15.4
* **Do you use a PostgreSQL SaaS? If so, which? Can you reproduce
the issue with a local PostgreSQL install?**: N/A, building the [`python-asyncpg` package](https://src.fedoraproject.org/rpms/python-asyncpg) on Fedora Linux infrastructure
* **Python version**: 3.12.0
* **Platform**: Fedora Linux Rawhide, ~~`s390x` architecture (only!)~~
* **Do you use pgbouncer?**: No
* **Did you install asyncpg with pip?**: No, I am the maintainer of the distribution package.
* **If you built asyncpg locally, which version of Cython did you use?**: 0.29.35
* **Can the issue be reproduced under both asyncio and
[uvloop](https://github.com/magicstack/uvloop)?**: ~~**No**, only `asyncio`.~~ *yes*

This is new in 0.29.0. I don’t have any idea why it is happening.

~~I can’t reproduce this with `PYTHONASYNCIODEBUG=1`, nor can I reproduce it with `USE_UVLOOP=1`.~~ I have now seen this on `x86_64` with `asyncio` and `PYTHONASYNCIODEBUG=1`.

~~I don’t have interactive access to an `s390x` machine, but~~ I am happy to run experiments or test proposed fixes by submitting package test builds on Fedora infrastructure. For the time being, I plan to simply skip this test ~~on `s390x`~~.

```
=================================== FAILURES ===================================
________ TestExecuteMany.test_executemany_server_failure_during_writes _________
Traceback (most recent call last):
File "/usr/lib64/python3.12/unittest/case.py", line 58, in testPartExecutor
yield
File "/usr/lib64/python3.12/unittest/case.py", line 634, in run
self._callTestMethod(testMethod)
File "/usr/lib64/python3.12/unittest/case.py", line 589, in _callTestMethod
if method() is not None:
^^^^^^^^
File "/builddir/build/BUILDROOT/python-asyncpg-0.29.0-1.fc40.s390x/usr/lib64/python3.12/site-packages/asyncpg/_testbase/__init__.py", line 92, in wrapper
self.loop.run_until_complete(coro)
File "/usr/lib64/python3.12/asyncio/base_events.py", line 664, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "/builddir/build/BUILD/asyncpg-0.29.0/tests/test_execute.py", line 215, in test_executemany_server_failure_during_writes
self.assertLess(pos, 128, 'should stop early')
File "/usr/lib64/python3.12/unittest/case.py", line 1257, in assertLess
self.fail(self._formatMessage(msg, standardMsg))
File "/usr/lib64/python3.12/unittest/case.py", line 715, in fail
raise self.failureException(msg)
AssertionError: 128 not less than 128 : should stop early
```

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 tests/test_execute.py 开始,重点查看第 215 行失败的断言附近的 TestExecuteMany.test_executemany_server_failure_during_writes。使用 Python 3.12、PostgreSQL 15.4 和 asyncio 重现测试,然后将观察到的 128 的位置与测试预期的提前停止进行比较。完成的标准是理解该失败,并且测试能够稳定通过,同时不添加没有充分依据的平台特定 skip。

由索引模型根据 Issue 内容生成。

评估

技术栈
postgresql, python
领域
backend, databases
Issue 类型
缺陷
难度
3/5
预计耗时
1-2 天
活跃度
停滞
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。