-
Notifications
You must be signed in to change notification settings - Fork 539
Fix closing SDK connections #10969
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix closing SDK connections #10969
Conversation
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
I think this one is still too aggressive, the only thing we should not retain are redap connections. Nothing else is 1 connection == 1 recording |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than that LGTM
let should_close = match &data_source { | ||
// Specific files should stop streaming when closing them. | ||
SmartChannelSource::File(_) => true, | ||
|
||
// Specific HTTP streams should stop streaming when closing them. | ||
SmartChannelSource::RrdHttpStream { .. } => true, | ||
|
||
// Specific GRPC streams should stop streaming when closing them. | ||
// TODO(#10967): We still stream in some data after that. | ||
SmartChannelSource::RedapGrpcStream { .. } => true, | ||
|
||
// Don't close generic connections (like to an SDK) that may feed in different recordings over time. | ||
SmartChannelSource::RrdWebEventListener | ||
| SmartChannelSource::JsChannel { .. } | ||
| SmartChannelSource::Sdk | ||
| SmartChannelSource::Stdin | ||
| SmartChannelSource::MessageProxy(_) => false, | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let should_close = match &data_source { | |
// Specific files should stop streaming when closing them. | |
SmartChannelSource::File(_) => true, | |
// Specific HTTP streams should stop streaming when closing them. | |
SmartChannelSource::RrdHttpStream { .. } => true, | |
// Specific GRPC streams should stop streaming when closing them. | |
// TODO(#10967): We still stream in some data after that. | |
SmartChannelSource::RedapGrpcStream { .. } => true, | |
// Don't close generic connections (like to an SDK) that may feed in different recordings over time. | |
SmartChannelSource::RrdWebEventListener | |
| SmartChannelSource::JsChannel { .. } | |
| SmartChannelSource::Sdk | |
| SmartChannelSource::Stdin | |
| SmartChannelSource::MessageProxy(_) => false, | |
}; | |
let should_close = matches!(data_source, SmartChannelSource::RedapGrpcStream { .. }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't want to use matches since it doesn't warn on new sources
Why would it not be the case for http and files? |
Because the |
I haven't tried to understand what is up with the other issue the previous PR fixed yet, maybe there's a different way to fix it? Also, hint hint nudge nudge cough #8631 cough |
in a nutshell we have the exact same issue you fixed for the grpc entries also with streaming from http: if you close a recording that streams from file or http, we also have to close the data sources otherwise recordings will show up again. In Debug this causes a debug assertion to trigger on top of that which your original PR fixes (and this PR tries to preserve by means of still removing those sources)
lalalala I can't hear you ;-) (in this pr at least 😄 ) |
that does make sense :/ except that it's quite the corner case. I think it's fair to say that the close on those recordings also closes the connection? It's a bit odd that we have this as a separate concept internally that we don't expose :( |
I think I agree, and it's an edge case that should eventually go away. Seems acceptable to tell people "don't remove the data source if you have more than one logical recording in it and you want to see both". It seems unlikely for people to even do that in the first place |
👍 but good you brought up this concern - I didn't really consider the possibility. We're clearly not "done" here! |
Related
What
previous PR was too aggressive: made the viewer "deaf" to anything from the SDK after closing one SDK originated recording