The shipper PublishEvents documentation currently specifies that it should block until processing is completed and events have been enqueued:

service Producer {
 // Publishes a list of events via the Elastic agent shipper.
 // Blocks until all processing steps complete and data is written to the queue.
 //
 // If the queue could not accept some events from the request, this returns a successful response
 // containing a count of events that were accepted by the queue.
 // The client is expected to retry sending the rest of the events in a separate request.
 // 
 // The client is also expected to have some kind of backoff strategy
 //	in case of a reply with an accepted count < the amount of sent events.
 rpc PublishEvents(messages.PublishRequest) returns (messages.PublishReply)

The initial gRPC server implementation however does not implement this behaviour: #76 (comment).

The scope of this issue is to decide whether the PublishEvents RPC should block when the queue is full, and then update either the RPC documentation or the server implementation based on the outcome.

There were two example scenarios provided in the original discussion:

Example 1. The queue filled up during the request (logic already in place)

1. The client requests to publish 50 events
2. The queue can accept only 5 and we get "queue is full" error back from publishing the 6th
3. The server replies to the client with the current AcceptedCount and AcceptedIndex values partially accepting the event batch

Example 2. The queue is full from the beginning (needs to be implemented)

1. The client requests to publish 50 events
2. When publishing the first event, the queue returns "queue is full" error and cannot accept even a single event
3. The server blocks the client when calling the underlying queue's Publish call.
4. Once at least one event is accepted by the queue this switches to the behaviour in Example

The behaviour proposed in the examples above are that PublishEvents would block until at least one event is accepted, and then return with the accepted count indicating how many events were accepted. The alternative would be blocking until all events are accepted.