Get desktop application:
View/edit binary Protocol Buffers messages
The performer should stream back responses as fast as it can.
Used in:
(message has no fields)
A request for the performer to cancel a stream. Exactly what this entails is context and SDK dependent. If the SDK's stream has the concept of user-cancellation, this should be invoked. At minimum, the performer should stop streaming responses from that stream to the driver. The performer can assume that if the driver tries to cancel a stream that doesn't exist (e.g. has stopped streaming), this is a driver bug. As a corollary, the driver will only cancel `stream_when.OnDemand` streams. Otherwise it would be a race as to whether the stream completes or is cancelled first. On cancellation the performer should not proceed to the next stage of streaming. E.g. it should not return a streams.Complete. But instead return a streams.Cancelled, after it has finished cancelling.
Used as request type in: PerformerService.streamCancel
The performer has successfully cancelled the stream. Due to the asynchronous nature of streaming and cancelling, a few items may still be streamed back to the driver after this is sent.
Currently empty, but included per GRPC best practices.
Used as response type in: PerformerService.streamCancel
(message has no fields)
A stream has finished being cancelled.
Used in:
A stream has finished sending back all results.
Used in:
Used in: , , , ,
The performer must use this as the subsequent stream id. (Having stream ids generated driver-side will make it much easier for the driver to handle concurrent tests in future.)
When the performer should stream back results.
The performer has created a stream and is notifying the driver of it.
Used in:
A stream raised an error.
Used in:
The performer must wait for the driver to request rows before streaming them.
Used in:
(message has no fields)
The driver (pretending to be the user) is requesting more items. For each item requested, the performer should fetch one from the stream, and stream back an appropriate response. Once all items in the stream have been streamed, the performer should automatically proceed to the next stage of streaming (usually to return a streams.Complete). FIT is aware that some implementations (such as Go), don't have any lookahead, and that if the user/driver requests N items on a N item stream, the implementation does not know the stream is complete yet - the user/driver needs to request item N+1 first. To simplify the performer logic, the performer can assume that if the driver does any of these, it is a driver bug. It should raise a standard GRPC UNKNOWN error code: 1. If the driver tries to do this with a stream that doesn't exist (e.g. has stopped streaming), 2. If the driver requests more items before the performer has finished streaming back the previously requested items. If the driver requests more items than are currently in the stream, this is not an error, the performer should stream back as many as it can, and then wait for more items so it can satisfy the request. If the performer knows the stream has finished and the driver has still requested too many items, this is also not a bug. The performer should continue to the next stage of streaming (usually to return a streams.Complete).
Used as request type in: PerformerService.streamRequestItems
Currently empty, but included per GRPC best practices.
Used as response type in: PerformerService.streamRequestItems
(message has no fields)
Used in:
Used in: