Pub/Sub Python: encode message data as bytes

Locate the failure before investigating delivery

Record the exception and the type passed as data. If the client rejects a string locally, subscriber health and topic delivery settings cannot explain that immediate error. First repair the boundary that the publisher actually rejected.

Our test passed JSON text to PublisherClient.publish and observed TypeError. No message reached the fixture for that call. After encoding the same object to bytes, one publish request arrived with the intended decoded business value.

Encode the application payload once

Keep the conversion explicit so the consumer contract remains understandable. JSON serialization decides the representation of the object; UTF-8 encoding decides how that text becomes bytes.

The helper below returns bytes containing one JSON object. It does not claim to validate every field in an order schema. Validate required business fields separately before publishing and avoid including secrets in the message body.

python · ÖRNEK

import json

def order_message(order_id):
    return json.dumps(
        {"order_id": order_id},
        ensure_ascii=False,
    ).encode("utf-8")

Publish through the existing configured client

Use the application’s long-lived publisher and a fully qualified topic path for the intended project. The following function accepts that client rather than creating a new one for every message.

Waiting for the future is useful in a controlled test because a queued message is not yet evidence of an accepted publish. In a high-throughput application, manage futures and errors through a deliberate batching and shutdown design instead of serially blocking after every production message.

python · ÖRNEK

def publish_order(publisher, topic_path, order_id):
    future = publisher.publish(topic_path, data=order_message(order_id))
    return future.result(timeout=10)

Keep REST Base64 out of the bytes contract

Direct REST requests represent message data using a Base64 string in JSON. The Python client library accepts the original message bytes and handles its transport. Base64-encoding your business payload first changes what a normal subscriber receives.

Test the consumer’s decoded object as well as the publisher’s return value. A publish can succeed while delivering an unintended Base64 text payload. The local gRPC fixture verified that the submitted message bytes decoded directly to the expected JSON object.

Verify the real end-to-end boundary separately

The fixture’s generated message ID proves only that the tested SDK path accepted the input and handled a local response. For production verification, use an approved test topic and observe the intended subscription or consumer through its normal permissions.

Keep publisher acceptance, delivery, and successful business processing as separate observations. Avoid logging entire customer payloads just to show that publishing works. A small test event with an identifiable, non-sensitive operation ID is easier to trace.

Sınırları bil

Reproduced with google-cloud-pubsub 2.43.0. A string raised TypeError locally; UTF-8 bytes passed through the actual SDK batching path to a local gRPC fixture. Its returned message ID was synthetic. No real topic, delivery, subscription, quota, or IAM behavior was tested.

Kaynaklar ve ileri okuma

CoreTrailKit tarafından hazırlanan teknik yayın.

Bütün yazıları keşfet