tree 47a6e87adc0ec023311e9a2b22294477dacc576b
parent be06550ff895afe52bd55f72607b2dfae0f59225
author Boris Zbarsky <bzbarsky@apple.com> 1731691651 -0500
committer GitHub <noreply@github.com> 1731691651 -0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJnN4SDCRC1aQ7uu5UhlAAA0RgQAFH7eV05kyzeh06tso8uJ2D/
 NeLEzPOcNPBgeH7YW3wSvGlZkfrPd6JNQfnO82lKNmim5iY+ddoIDJ1B1U4UAQWo
 0pWIKy2dxmB4Xga3W7KU1KxpyjyhkzfNs8uNLqpidNYzO8qld9pLWVV+9Ka1OUOz
 A/J1hHwX4yGN/VS4v1vKlSwlDbotImCYNnUWoSQkynE7jws1JDuE1uV1choq/+nS
 ivthz86KvenvJjyPAFCSplCsDtfTKkyJ3YSQviE/mJ+vxcGRqBuiQnQ5YKJmJriZ
 apLSFTkFlbSLcBOQFsQRwsJTgHrZaEzm/Eg1Ad6n28VzChrAvgwxInahVtmAbsa4
 gUFKUiXYLQ5axX43NWPvNLUoSm+YEKV7zOV3kF4tAjiNkvdfGbJNJIf7oCGYlTsP
 iRl0OrEWwxj/9WhShAl+Z6MyaoMpHNeX7mE0senVp1hdYi+CwM656p2dZ4p0uR/m
 s7wBESUV3lPfg49daIH9YZ0R6g+J4XI0bfAhECioBm60tZiSKkOdXGVnXfehBURh
 p+eIF7uqsNighOIqWHH3W5oS3QCnVZT5rIjw1E5UH5wTKSkxM6Nr3+emBusz9Jpo
 86K15+PWauu/K1ONABB92WoGuFzsNXJVJro+gvw/rw21eqmG6zK4A44gSoLbyvZG
 T/UTotJNVI2SuNJ5FUn4
 =PknI
 -----END PGP SIGNATURE-----
 

Improve detection of "historical" events in Matter.framework. (#36506)

We were marking events as "historical" if there were any attributes in the same
report that have the C quality. This had a few problems:

* Some devices randomly report C-quality attributes, for various reasons.
* Some attributes stop having the C quality in favor of Q, in some cases, so
  this is not very forward-compatible.

The fix is to remove this C-quality check altogether.  At that point we have the
following situations:

1. We're setting up a new subscription and getting our initial priming report.
   This case will still have _receivingPrimingReport set, and will cause any
   events reported as part of priming to be marked "historical".
2. We are getting a "priming" report from a server-side subscription resumption
   after the server timed out on a subscription.  If this happens before the
   max-interval elapses, we will see this as a normal report on our
   subscription, but with all attributes and events the server knows about
   included.  In this case, we mark ourselves as being in a "priming report" if
   we get an event that has an event number we have already seen, so that we
   mark any not-seen-before events in that report as "historical", since we
   don't know how long ago they are from.
3. We are getting a normal incremental report, and will not mark any such events
   as "historical".

Since we are now keeping track of last-received event numbers, we can also use
those for our subscriptions and can filter out any events that have an event
number no greater than our last-observed one.