Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 34 additions & 7 deletions src/bitdrift_public/protobuf/client/v1/api.proto
Original file line number Diff line number Diff line change
Expand Up @@ -34,19 +34,36 @@ message ClientKillFile {
google.protobuf.Timestamp kill_until = 2;
}

// This is sent both in the initial handshake as well as mid-stream if any of the attributes have
// changed. The handshake will fill in all values as part of an initial update.
message StateUpdateRequest {
message StartedSession {
// The session ID of the started session.
string session_id = 1;
// The start time of the session.
google.protobuf.Timestamp start_time = 2;
}

message OpaqueEntityUpdate {
// If one has been supplied, the opaque entity ID. If an update is sent that nulls this out
// it means that the unique entity is no longer bound (for example after a logout).
optional string opaque_entity_id = 1;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so during offline reconnect we'd just be sending the latest value of this? any reason we'd want to be able to see all changes or do we think that it's low frequency enough that this doesn't matter?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose I could make this keep track of all changes as I'm going to do with sessions it just seems like an extreme edge case. I will discuss with @Reflejo

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per offline convo for now we will just send the most recent one. We are going to store entity changes in state though which should make changes visible in timeline once we finish that work.

}

// The opaque entity update.
OpaqueEntityUpdate opaque_entity_update = 1;

// The list of started sessions.
repeated StartedSession started_sessions = 2;
}

// The initial request sent over the stream.
message HandshakeRequest {
// A set of opaque metadata that identifies the connecting device. These will
// remain static for the duration of this stream.
// TODO(snowp): Support updating these throughout the session.
// TODO(snowp): Improve the story for this when parameters change during a
// logging period, e.g. if we capture multiple process restarts that may span
// versions.
// TODO(snowp): Support updating these throughout the session / move to StateUpdateRequest.
map<string, logging.v1.Data> static_device_metadata = 1;

// This was never used by the client. Reserve it for now to avoid implementing it. We can bring
// it back later if needed.
reserved "fields_for_all_logs";
reserved 2;

// If the client has an active configuration, previously obtained via a ConfigurationUpdate
Expand Down Expand Up @@ -74,6 +91,12 @@ message HandshakeRequest {
// should continue to send this on every handshake request until the server provides a new
// value (which may be empty to clear existing state).
optional bytes opaque_client_state = 8;

// When the handshake request is sent an initial state update will be included with both
// the opaque entity ID (if provided) as well as at least the current session. There may be
// multiple sessions included if some session transitions have happened while offline and have
// not yet been sent to the server.
StateUpdateRequest state_update = 9;
}

// Notifies the server about the intent to upload one or more batches of logs. The client is expected (but
Expand Down Expand Up @@ -210,6 +233,7 @@ message ApiRequest {
UploadArtifactRequest artifact_upload = 12;
UploadArtifactIntentRequest artifact_intent = 13;
DebugDataRequest debug_data = 14;
StateUpdateRequest state_update = 15;
}

reserved 8;
Expand Down Expand Up @@ -603,6 +627,8 @@ message DebugDataRequest {
map<string, WorkflowDebugData> workflow_debug_data = 1;
}

message StateUpdateResponse {}

// A multiplexed response sent over the bitdrift API.
message ApiResponse {
oneof response_type {
Expand All @@ -621,6 +647,7 @@ message ApiResponse {
SankeyIntentResponse sankey_intent_response = 13;
UploadArtifactResponse artifact_upload = 14;
UploadArtifactIntentResponse artifact_intent = 15;
StateUpdateResponse state_update = 16;
}

reserved 10;
Expand Down
3 changes: 3 additions & 0 deletions src/bitdrift_public/protobuf/workflow/v1/workflow.proto
Original file line number Diff line number Diff line change
Expand Up @@ -88,8 +88,11 @@ message Workflow {
message Rule {
oneof rule_type {
option (validate.required) = true;

RuleLogMatch rule_log_match = 1;
RuleStateChangeMatch rule_state_change_match = 3;
// This will match when a new session starts.
bool on_new_session = 4;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about using RuleStateChangeMatch for this but it doesn't really fit cleanly and IMO it makes more sense to keep this independent but let me know if you think otherwise.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes sense in general since using RuleStateChangeMatch would expose the actual session ID for matching which I think adds more complexity than is necessary

}

reserved 2;
Expand Down
Loading