Re: [PATCH 2/3] iotests: port 141 to Python for reliable QMP testing

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

On Wed, Jan 17, 2024 at 07:04:06PM +0100, Kevin Wolf wrote:
> Am 16.01.2024 um 20:00 hat Stefan Hajnoczi geschrieben:
> > The common.qemu bash functions allow tests to interact with the QMP
> > monitor of a QEMU process. I spent two days trying to update 141 when
> > the order of the test output changed, but found it would still fail
> > occassionally because printf() and QMP events race with synchronous QMP
> > communication.
> > 
> > I gave up and ported 141 to the existing Python API for QMP tests. The
> > Python API is less affected by the order in which QEMU prints output
> > because it does not print all QMP traffic by default.
> > 
> > The next commit changes the order in which QMP messages are received.
> > Make 141 reliable first.
> > 
> > Cc: Hanna Czenczek <hreitz@redhat.com>
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> 
> iotests 297 finds problems with the new Python code:
> 
>  === pylint ===
> +************* Module 141
> +141:82:0: C0301: Line too long (86/79) (line-too-long)
> +141:93:0: C0301: Line too long (86/79) (line-too-long)
> +141:94:0: C0301: Line too long (80/79) (line-too-long)
> +141:106:0: C0301: Line too long (85/79) (line-too-long)
> +141:107:0: C0301: Line too long (82/79) (line-too-long)
> +141:109:0: C0301: Line too long (82/79) (line-too-long)
> +141:117:0: C0301: Line too long (86/79) (line-too-long)
> +141:120:0: C0301: Line too long (86/79) (line-too-long)
> +141:129:0: C0301: Line too long (86/79) (line-too-long)
>  === mypy ===
> +141:104: error: Value of type variable "Msg" of "log" cannot be "dict[str, Any] | None"  [type-var]
> +141:114: error: Value of type variable "Msg" of "log" cannot be "dict[str, Any] | None"  [type-var]
> +Found 2 errors in 1 file (checked 37 source files)

I'm not sure how to run this but I manually ran pylint and mypy and
fixed those errors. Can you share how you ran this?

The mypy errors are because the type system cannot express that
event_wait() only returns None when timeout=0. That's not the case in
141 but mypy complains anyway, so I added an assertion that event is not
None to silence mypy.

Thanks,
Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]