Bidirectional provider implementation #149
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #149 +/- ##
==========================================
- Coverage 63.77% 62.59% -1.18%
==========================================
Files 36 37 +1
Lines 17637 18293 +656
==========================================
+ Hits 11248 11451 +203
- Misses 6389 6842 +453 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
rafaeling
force-pushed
the
bidirectional-provider-implementation
branch
3 times, most recently
from
4117bb6 to
e06d186
Compare
rafaeling
force-pushed
the
bidirectional-provider-implementation
branch
from
a9ab8a7 to
26d129c
Compare
| @@ -124,7 +136,8 @@ pub struct Database { | |||
| pub struct Subscriptions { | |||
| actuation_subscriptions: Vec<ActuationSubscription>, | |||
| query_subscriptions: Vec<QuerySubscription>, | |||
| change_subscriptions: Vec<ChangeSubscription>, | |||
| change_subscriptions: HashMap<Uuid, ChangeSubscription>, | |||
There was a problem hiding this comment.
why store uuid two times and not make another field id instead?
| @@ -202,8 +239,10 @@ pub struct QuerySubscription { | |||
|
|
|||
| pub struct ChangeSubscription { | |||
| entries: HashMap<i32, HashSet<Field>>, | |||
| sender: broadcast::Sender<EntryUpdates>, | |||
| sender: broadcast::Sender<Option<EntryUpdates>>, | |||
There was a problem hiding this comment.
this is a rather big concept change right?
There was a problem hiding this comment.
Yes, it is. I thought a lot about also introducing a new channel field to control when and how a subscription should get notified when provider goes away (for the 3 API versions). Adding the Option field was the least breaking change that would still work with all APIs.
In my opinion, we should start at some point removing old APIs and code, it is getting really messy.
| /// the new update filter map containing ONLY signals_ids along with | ||
| /// their new lowest interval_ms. | ||
| /// | ||
| pub fn add_new_update_filter( |
There was a problem hiding this comment.
align naming e.g. add_new_update_filter and remove_filter_by_subscription_uuid make it clear that this is the same filter we're talking about
There was a problem hiding this comment.
please do not check in generated files
There was a problem hiding this comment.
For sdv API were already there for the integration test, if I dont add them integration test would not work
| @@ -17,5 +17,6 @@ bdd_features_base_dir = "features" | |||
| viss_ws_base_url = ws://localhost:8090 | |||
| viss_http_base_url = http://localhost:8090 | |||
| viss_mqtt_base_url = mqtt://localhost:1883 | |||
| viss_grpc_base_url = localhost:55555 | |||
There was a problem hiding this comment.
grpc:// would be better
| #[derive(Deserialize)] | ||
| #[serde(rename_all = "camelCase")] | ||
| pub struct TimebasedFilter { | ||
| pub period: u32, |
There was a problem hiding this comment.
This filter seems to be incorrect. The parser rejects subscriptions formatted according to the specification:
{"action": "subscribe", "path": "abc", "requestId": "1", "filter": {"type": "timebased", "parameter": {"period": 500}}}
Introduced the FilterManager structure to manage filter subscriptions based on the lowest time interval.
Added new fields to the Subscriptions struct to manage ChangeSubscription and Providers by their UUID.
Modified sender: broadcast::Sender in ChangeSubscription to sender: broadcast::Sender<Option> to allow receiving None when the sender is gone. This enables returning an error (VISS case) or None to the consumer.
Implemented logic to propagate time-based filters to providers, notify subscriptions according to the time interval, and claim signals by providers during startup.
Added VISS subscription integration tests.