You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When performing an RPC call with a TestRabbitBroker where the subscriber returns a pydantic model, the response type is different depending on whether the test runs with a mock broker or a real RabbitMQ broker.
How to reproduce
Save the code below as example.py, then run pytest example.py. The test will pass.
I would expect the return type of the RPC call to be the same for both with_real=False and with_real=True. Ideally, I'd like to be able to specify the pydantic model as the return type even if I'm using a real RabbitMQ broker (see case 2 in #1228). In the absence of this feature, it would be good if the TestRabbitBroker could also return a plain dict so that I don't have to add case distinctions in all my tests.
Observed behavior
For with_real=False, the return type is a proper pydantic model, whereas for with_real=True it is a plain dict.
Environment
$ faststream -v
Running FastStream 0.5.5 with CPython 3.12.3 on Darwin
The text was updated successfully, but these errors were encountered:
I just realised that the impact of this bug is worse than just requiring case distinctions in tests.
I had implemented some features in a test-driven way using TestRabbitBroker. All the tests pass, but the app itself (not just the tests) broke when I switched to the real RabbitMQ broker because in one of my message handlers I'm accessing an attribute response.status. This works with the mock broker because response is a pydantic model that has a status attribute. However, when using the real broker, response is suddenly a plain dictionary so I would need to access the field via response["status"] instead.
I would like to catch this issue early during development with the mock broker, not just after the fact when switching to the real one.
Lancetnik
added
the
Core
Issues related to core FastStream functionality and affects to all brokers
label
May 16, 2024
Well, it is a bug indeed, thank you for finding it. I suppose, we should return serializaed message from the TestBroker rpc instead of python objects the same way with the mock behavior
Describe the bug
When performing an RPC call with a
TestRabbitBroker
where the subscriber returns a pydantic model, the response type is different depending on whether the test runs with a mock broker or a real RabbitMQ broker.How to reproduce
Save the code below as
example.py
, then runpytest example.py
. The test will pass.Now change the value of
with_real
toTrue
and run it again. This time it raises an error because the response type of the RPC call is a plain dict:Expected behavior
I would expect the return type of the RPC call to be the same for both
with_real=False
andwith_real=True
. Ideally, I'd like to be able to specify the pydantic model as the return type even if I'm using a real RabbitMQ broker (see case 2 in #1228). In the absence of this feature, it would be good if theTestRabbitBroker
could also return a plain dict so that I don't have to add case distinctions in all my tests.Observed behavior
For
with_real=False
, the return type is a proper pydantic model, whereas forwith_real=True
it is a plain dict.Environment
The text was updated successfully, but these errors were encountered: