File: cqg_api/cqg_request.proto
Report from the new CQG data delivery system.
Type: uint64
Description: ID(s) of the corresponding request(s).
In most cases, the request_ids field contains a single ID. Special cases involving multiple IDs are described in the comments of the corresponding request types.
Type: Status
Description: Report status.
Type: shared_1.Text
Description: Optional failure details.
Type: uint32
Description: Report type ID is provided for convenience.
This field is always set and equal to the request_type_id of the corresponding request.
Type: bytes
Description: Serialized report message of the above specified type.
This field is omitted if the report status changes but there is no data to send to the client. For example, STATUS_DISCONNECTED. For more information, see the comments for the Status enum values.
Description: Report status.
Main status sequences:
1. For requests with KIND_GET and KIND_ACTION:
o Zero or more STATUS_SNAPSHOT_CHUNK, followed by STATUS_COMPLETED
2. For requests with KIND_SUBSCRIBE:
o STATUS_SUBSCRIBED, without data
o Zero or more STATUS_SNAPSHOT_CHUNK, followed by STATUS_SNAPSHOT_FINAL (initial snapshot)
o Zero or more STATUS_UPDATE_CHUNK, followed by STATUS_UPDATE_FINAL (incremental update)
o Zero or more STATUS_SNAPSHOT_CHUNK, followed by STATUS_SNAPSHOT_FINAL (snapshot after update)
A snapshot replaces previously received data; an update modifies previously received data. How update is applied depends on request type, and is documented in the comments for specific request type.
When a snapshot or update is too large to be sent in a single message, it is split into chunks sent sequentially. If the client can process incomplete data (e.g., to display it in a dynamic table), it may process chunks as they arrive. If the client needs complete data (e.g., to calculate summary), it should collect all chunks and process the full message only after the final chunk with STATUS_SNAPSHOT_FINAL, STATUS_UPDATE_FINAL, or STATUS_COMPLETED.
•STATUS_UNSPECIFIED = 0
•STATUS_UPDATE_CHUNK = 1
Chunk of a data update; more chunks are expected.
•STATUS_UPDATE_FINAL = 2
Last or only chunk of a data update.
•STATUS_SNAPSHOT_CHUNK = 3
Chunk of a data snapshot; more chunks are expected.
•STATUS_SNAPSHOT_FINAL = 4
Last or only chunk of a data snapshot.
•STATUS_COMPLETED = 5
Final response for non-subscription requests.
This status includes the last snapshot chunk.
•STATUS_SUBSCRIBED = 6
Subscription has been accepted (in response to KIND_SUBSCRIBE).
Reports with this status never include the serialized_report field.
•STATUS_DROPPED = 7
Request has been dropped (in response to KIND_DROP).
Reports with this status never include the serialized_report field.
•STATUS_DISCONNECTED = 8
Request or subscription has been paused because a service dependency is currently unavailable.
Depending on request kind and request type, the request may or may not be restored automatically:
o Requests with KIND_GET may fail with STATUS_FAILED (not restored) or may send STATUS_DISCONNECTED followed by new responses with STATUS_SNAPSHOT_CHUNK and/or STATUS_COMPLETED.
o Requests with KIND_ACTION are not restored and fail with STATUS_FAILED.
o Subscriptions (requests with KIND_SUBSCRIBE) send STATUS_DISCONNECTED followed by a response with STATUS_DROPPED_AVAILABLE_FOR_RESUBSCRIBE (if automatic subscription restore is not possible) or new responses with STATUS_SUBSCRIBED, zero or more STATUS_SNAPSHOT_CHUNK, and STATUS_SNAPSHOT_FINAL.
Reports with this status never include the serialized_report field.
•STATUS_DROPPED_AVAILABLE_FOR_RESUBSCRIBE = 9
Server is ready to accept new subscription requests.
The client may retry the subscription with the same or updated parameters.
Reports with this status never include the serialized_report field.
•STATUS_FAILED = 100
The request has failed, with a reason described in the details field.
Reports with this status typically do not include the serialized_report field.