Refactor ConnectionsAndStatsStore responsibility #2737
Conversation
# Conflicts: # src/Frontend/src/components/failedmessages/PendingRetries.vue
| const [response] = await serviceControlClient.fetchTypedFromServiceControl<FailedMessage>(`errors?status=${status}`); | ||
| return parseInt(response.headers.get("Total-Count") ?? "0"); |
There was a problem hiding this comment.
| const [response] = await serviceControlClient.fetchTypedFromServiceControl<FailedMessage>(`errors?status=${status}`); | |
| return parseInt(response.headers.get("Total-Count") ?? "0"); | |
| return await serviceControlClient.getErrorMessagesCount(status); |
| //Refresh is handled by the autoRefresh setup on the respective views, so doing it here also would cause a double refresh | ||
| //await refresh(); |
There was a problem hiding this comment.
I think this is valuable commentary, since I had a refresh here and only removed it when I realised a double refresh was occurring, at which point I needed to investigate the reason why
| startDate.value = newStartDate; | ||
| [archivedMessageCount.value, pendingRetriesMessageCount.value] = await Promise.all([getErrorMessagesCount(FailedMessageStatus.Archived), getErrorMessagesCount(FailedMessageStatus.RetryIssued)]); | ||
|
|
||
| if (!messageStatus) { |
There was a problem hiding this comment.
we're now going to have to clear messageStatus on unloading any views. This seems clunky to me, since the archivedMessageCount and pendingRetriesMessageCount have been placed in this store when they have nothing to do with the rest of the data which is loaded by this store.
IMO this is a worse solution than having it in the connectionandstatsstore with the flag to identify whether to bother fetching it or not
| const showPendingRetry = window.defaultConfig.showPendingRetry; | ||
| const { store: connectionsAndStatsStore } = useConnectionsAndStatsAutoRefresh(); | ||
| connectionsAndStatsStore.requiresFullFailureDetails(); | ||
| const { autoRefresh } = useStoreAutoRefresh("recoverabilityStore", useRecoverabilityStore, 5000); |
There was a problem hiding this comment.
because this is using useStoreAutoRefresh rather than a singleton version, this will result in two versions of the autorefresh on the recoverability store?
This PR moves archived and pending retry message count tracking from
ConnectionsAndStatsStoretoRecoverabilityStorefor better separation of concerns. TherequiresFullFailureDetails()subscription pattern has been removed -RecoverabilityStorenow fetches these counts directly on each refresh. Additionally, refactoredRecoverabilityStorerefresh function for improved maintainability.