Skip to content

kns: Centralise the backend query state handling

Aleix Pol Gonzalez requested to merge work/kns-correct into master

We put it all into ::setResponsePending which is the function that we call to tell we are embarking on a new query. This allows us to make sure the signals to wrap up the previous state can be emitted as well as notifying about the new state accordingly. This also allows us to assert when the state isn't as expected, which allowed to address some issues already as it's done in this change.

Hence, this fixes:

  • issuing 2 searches before the backend has initialised will result in an infinite job as both queries would be waiting forever for the backend to initialise.
  • issuing 2 searches where the first is pageable would leave the second idling forever even though it's the one we care about.
  • checking for updates didn't check whether we are already querying, we could get 2 tasks weirdly overlapping
  • fetchMore wouldn't notify about starting to fetch
  • fetchEntryById isn't paged
  • findResourceByPackageName wouldn't reset the m_responsePending value

BUG: 432965 CCBUG: 436373

Merge request reports