-
Notifications
You must be signed in to change notification settings - Fork 226
Bug: Custom Serialization/Deserialization logic in Redis doesn't work unless UTF-8 serializable #2061
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
Comments
You can pass default redis-py option right to the broker constructor to control this behavior: |
Sorry, I got the problem just now. Here is a full MRE from msgpack import packb
from faststream import FastStream, Logger
from faststream.redis import RedisBroker
broker = RedisBroker()
app = FastStream(broker)
@broker.subscriber("tests")
async def handler(data, logger: Logger):
logger.info(f"Received data: {data}")
@app.after_startup
async def start():
await broker.publish(
packb({"id": "12345678" * 4, "date": "2021-01-01T00:00:00Z"}),
"tests",
) |
I think, we should reinvent our own message format to publish |
Is the issue that you have to wrap whatever the client message is so that you get the necessary metadata you need on the receiving end? |
Yeah, we have to use headers. Therefore we made our own message format, but I designed it bad and you faced with a serialization problem. I think, we should redisign RowMessage - |
I might be missing something. It looks like swapping json with msgpack is just enough to resolve the problem. |
It's not an our dependency, so we couldn't use it there |
Encountered this while using protobuf so +1 on this too. |
Describe the bug
I am working on a middleware to add msgpack serialization to all messages (using ormsgpack which natively handles Pydantic models).
The issue seems to be that Faststream JSON-serializes messages along with header here:
Technically msg.data is supposed to be able to be bytes but in practice it has to be utf-8 compatible or it raises an exception:
Here's some test code:
The error is occurring on the producer side and the only workaround I've found so far is doing a runtime monkey-patch of the RawMessage.encode method so do the msgpack serialization at the final messaging encoding phase. This complicates things on the parsing side though as it breaks the normal message parsing (i.e. in order to get message headers, correlation_id, etc)
Any suggestions? Perhaps there needs to be additional Middleware hooks for handling the final message serialization and initial message deserialization so that serialization methods that utilize non utf-8 compatible binary are supported?
The only other option I can think of is base64 encoding the binary before message serialization which would kind of defeat the space-saving purpose of using a binary format.
Related: #1255
The text was updated successfully, but these errors were encountered: