-
Notifications
You must be signed in to change notification settings - Fork 19
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/db_creation_runtime_crash #214
fix/db_creation_runtime_crash #214
Conversation
…ll_entries, get and deletion exhibiting similar behaviour
PR missing one of the required labels: {'dependencies', 'bug', 'internal', 'breaking-change', 'new feature', 'enhancement', 'documentation'} |
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.
I am not comfortable with the Tokio executor management so, from my limited understanding, I don't see any issue 👍
I will let @evshary approve
a DELETE message seems to still trigger a runtime error.
|
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.
I think we might have a more consistent to decide when to use await_task
.
The reason we need await_task
is that the async fn (put
, del
...) inside the impl trait (like Volume
/ Storage
) can't await the async task directly. They can't get the current Runtime and need to use the Runtime inside plugins.
Therefore the better way here is that we only apply await_task
to the function related to the trait Volume
and Storage
. Besides, we still use the normal await.
For example,
We don't need to use await_task
inside get_deletion_timestamp
, but use it here.
zenoh-backend-influxdb/v2/src/lib.rs
Line 522 in da692f1
if let Some(del_time) = self.get_deletion_timestamp(measurement.as_str()).await? { |
We can ensure consistency in this way, and developers can easily know what we're doing.
BTW, just as @oteffahi reported, there are some missing parts in put and del
zenoh-backend-influxdb/v2/src/lib.rs
Line 522 in da692f1
if let Some(del_time) = self.get_deletion_timestamp(measurement.as_str()).await? { |
zenoh-backend-influxdb/v2/src/lib.rs
Line 557 in da692f1
match self |
zenoh-backend-influxdb/v2/src/lib.rs
Line 595 in da692f1
if let Err(e) = self |
zenoh-backend-influxdb/v2/src/lib.rs
Line 625 in da692f1
if let Err(e) = self |
Now I'm thinking of moving blockon_runtime
and await_task
to Zenoh and then every plugin does not need to define them by itself.
But it's beyond the PR.
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.
LGTM
I can also run the test successfully, but I'll leave @oteffahi to do the final test since I couldn't reproduce the DEL panic.
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.
LGTM. Other unrelated issues were found. Will address them in another PR.
…ll_entries, get and deletion exhibiting similar behaviour