Current behavior:

If a subscription exists, we don't create/update the DataRequest, so it still uses older values present in it.

Expected behavior:

Resubscribing to same filter should update the DataRequest

as per standards at [MQTT-3.8.4-3] :

If a Server receives a SUBSCRIBE Packet containing a Topic Filter that is identical to an existing Subscription’s Topic Filter then it MUST completely replace that existing Subscription with a new Subscription. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its maximum QoS value could be different. Any existing retained messages matching the Topic Filter MUST be re-sent, but the flow of publications MUST NOT be interrupted

Example

client
  .subscribe("hello", QoS::AtMostOnce)
  .await
  .unwrap();

client
  .subscribe("hello", QoS::ExactlyOnce)
  .await
  .unwrap();

// after this call, our QoS level for "hello" should be updated to ExactlyOnce
// but it still stays AtMostOnce!

Possible Solution

If a subscription ( DataRequest ) exists already here, we should get that DataRequest and update it. To find it, I can think of something like this:

self.scheduler.trackers[id]
    .data_requests
    .iter_mut()
    .find(|r| r.filter_idx == filter_idx)

This may or may not work depending on where the data request is. for example, the DataRequest can be in waiters as well!

PS: Would love to know if there exists any better way to find & update the DataRequest!