PublishStream RPC Method

The PublishStream method uses bidirectional streaming. It can send a stream of publish requests while receiving a stream of publish responses from the server. Use PublishStream to achieve a higher publish rate than with Publish.

The first PublishRequest of the stream identifies the topic to publish on. If a subsequent PublishRequest provides topic_name, it must match what was provided in the first PublishRequest. Otherwise, the RPC sends an error with an INVALID_ARGUMENT status.

The server returns a PublishResponse for each PublishRequest when publishing is complete for the batch. A client doesn’t have to wait for a PublishResponse before sending a new PublishRequest. Multiple publish batches can be queued up. This behavior allows for a higher publish rate because a client can asynchronously publish more events while publish operations are still in flight on the server side.

The PublishResponse holds a PublishResult for each event published that indicates success or failure of the publish call. A successful status means that the event was published and is in the event bus. A failed status means that the event failed to publish.

For more information about the fields in PublishRequest and PublishResponse, see the Pub/Sub API proto file.

The event id field in a PublishRequest, ProducerEvent.id, identifies an event published. It can be either system-generated or user-provided. If you don't specify an id value in the PublishRequest and the publish call succeeds, PublishResult.correlationKey is populated with a system-generated UUID. If the publish call fails, PublishResult.correlationKey is empty. When publishing an event, you can specify a custom id value in ProducerEvent.id. If you set a custom id, the PublishResult.correlationKey field in the returned PublishResponse is the custom id value for successful and failed publish calls. The custom id value can be any string up to 36 characters. We recommend specifying a unique id value, such as a UUID.

If the publishing fails due to a malformed event payload or a missing schema_id field, fix your request and try publishing again. If the cause of the publishing failure is due to a temporary server issue, retry publishing. To be able to retry publishing events, set the ProducerEvent id value in PublishRequest in the PublishStream call to a custom id value. When the PublishStream call fails, the returned PublishResult in PublishResponse contains the correlationKey field that is set to the id value you provided. Match PublishResult.correlationKey with ProducerEvent.id (the event ID) to identify the event published. You can then republish the event. It is advisable to limit the number of retries so your publish calls don't execute too many times in case the publishing keeps failing.

To hold onto the stream, a client must send a valid publish request with one or more events every 70 seconds. Otherwise, the server closes the stream and notifies the client. When the client is notified of the stream closure, it must make a new PublishStream call to resume publishing.