Skip to content
Commit c0e9cb93 authored by Aleix Pol Gonzalez's avatar Aleix Pol Gonzalez 🐧 Committed by Aleix Pol Gonzalez
Browse files

kns: Centralise the backend query state handling

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
parent df8c88b5
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment