feat: add temporality state to update message #567
Conversation
0xPoe
force-pushed
the
rustin-patch-state
branch
3 times, most recently
from
42f9bc6 to
73331fd
Compare
0xPoe
left a comment
0xPoe
left a comment
There was a problem hiding this comment.
This is not a perfect solution to fully solve this problem.
It can only be used before the new client starts, for already running clients, it doesn't help, because there is no message sent to that second client.
0xPoe
changed the title
This field can be used to check if the stream has been paused.
0xPoe
force-pushed
the
rustin-patch-state
branch
from
68064d6 to
5f847ec
Compare
hds
left a comment
hds
left a comment
There was a problem hiding this comment.
I think that putting the pause/live state into a separate update stream would make it flexible enough to update all clients that the subscriber is paused.
| warnings::Linter, | ||
| }; | ||
| use console_api as proto; | ||
| use console_api::instrument::Temporality; |
There was a problem hiding this comment.
For all other items used from the console_api crate, we reference by the "full" path (but starting with proto), I think we should do the same here to not make Temporality different.
| use console_api::instrument::Temporality; |
| current_view: &view::ViewState, | ||
| update: proto::instrument::Update, | ||
| ) { | ||
| match Temporality::try_from(update.temporality) { |
There was a problem hiding this comment.
Perhaps best to stick to the way that we reference all other types from the console_api crate.
| match Temporality::try_from(update.temporality) { | |
| match proto::instrument::Temporality::try_from(update.temporality) { |
| } | ||
|
|
||
| // The time "state" of the aggregator. | ||
| enum Temporality { |
There was a problem hiding this comment.
I think it would make sense to add another rpc for console subscriber state updates. Right now temporality would be the only thing in there, but this would allow us to do "out of band" state updates such as this case, where no data is being sent.
This would also allow us to solve the issue with already connected clients, as we could send this new server state update without needing to send a real update, so all connected tokio console instances would get the pause update.
What do you think?
There was a problem hiding this comment.
Sounds good! It would be a good solution.
|
Finally, I have some time to work on it again. I will try to add a new API for it. |
2 participants
close #551
This PR added a new field to the console's update message. Clients can use it to check if the subscriber stream is paused.
For example:
