You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current behavior
In RelevantRunSpecsDataSource, file the logic for calculating the spec counts used to show the progress of a running build in Cypress Cloud is in the #calculateSpecMetadata method. It makes a best attempt to figure out the status by looking across the statuses of each group. This is not the same way the cloud does it, so when looking at the Debug page or in the Cloud, the counts will not match up.
Desired behavior
The Cloud team is adding two new fields to the CloudRun type to supply the counts instead of having them be calculated in the app. That work will be done here: https://cypress-io.atlassian.net/browse/CYCLOUD-860
NOTE Cloud story is scheduled for Cloud sprint starting 2/8/23. Consider reaching out to the Cloud team when working on this (Tyler B).
The two new fields are documented as completedInstanceCount and totalInstanceCount. These values should be used in RelevantRunSpecsDataSourceinstead of pulling thespecs` field and trying to calculate the value with filtering, etc.
Additional refactors
Refactor subscription and poller to only watch one runNumber * The poller setup in this file in the pollForSpecs function backs the relevantRunSpecChange subscription. This subscription is used by both the DebugNewRelevantRunBar and the DebugPendingRunSplash. The DebugNewRelevantRunBar asks for the next field and the DebugPendingRunSplash asks for the current field, but the query will ask the Cloud for both if both a current and next run number has been calculated by the RelevantRunsDataSource. Refactor this datasource to take a parameter for the subscription that will just poll for the runNumber that is important to the component that subscribes. This will remove the need for having to alias runByNumber to both current and next.implemented this but removed changes after review with Stokes, based on upcoming work in same area
Only invalidate if watching current
Currently the poller in RelevantRunSpecsDataSource will call cache.invalidate if it detects a status change of either build it is watching (current or next). When the subscription is being used to watch the "next" run and the Debug page is showing the DebugNewRelevantRunBar, it does not need to perform the cache invalidation because the front end has not cached any queries. Currently, this use case causes the Debug page to flash the loading skeleton when the DebugNewRelevantRunBar transitions from the running to completed state. With the refactor in the previous bullet, update the cache invalidation to only happen on a status change when watching the current run.
Update comments
The comments for the class and the getRelevantRunSpecs method are incorrect. They were copy/pasted from the RelevantRunsDataSource. They should be updated to reflect what this file does.
The text was updated successfully, but these errors were encountered:
Current behavior
In
RelevantRunSpecsDataSource
, file the logic for calculating the spec counts used to show the progress of a running build in Cypress Cloud is in the#calculateSpecMetadata
method. It makes a best attempt to figure out the status by looking across the statuses of each group. This is not the same way the cloud does it, so when looking at the Debug page or in the Cloud, the counts will not match up.Desired behavior
The Cloud team is adding two new fields to the
CloudRun
type to supply the counts instead of having them be calculated in the app. That work will be done here: https://cypress-io.atlassian.net/browse/CYCLOUD-860NOTE Cloud story is scheduled for Cloud sprint starting 2/8/23. Consider reaching out to the Cloud team when working on this (Tyler B).
The two new fields are documented as
completedInstanceCount
andtotalInstanceCount
. These values should be used in RelevantRunSpecsDataSourceinstead of pulling the
specs` field and trying to calculate the value with filtering, etc.Additional refactors
* The poller setup in this file in theimplemented this but removed changes after review with Stokes, based on upcoming work in same areapollForSpecs
function backs therelevantRunSpecChange
subscription. This subscription is used by both theDebugNewRelevantRunBar
and theDebugPendingRunSplash
. TheDebugNewRelevantRunBar
asks for thenext
field and theDebugPendingRunSplash
asks for thecurrent
field, but the query will ask the Cloud for both if both a current and next run number has been calculated by theRelevantRunsDataSource
. Refactor this datasource to take a parameter for the subscription that will just poll for the runNumber that is important to the component that subscribes. This will remove the need for having to aliasrunByNumber
to both current and next.RelevantRunSpecsDataSource
will callcache.invalidate
if it detects a status change of either build it is watching (current or next). When the subscription is being used to watch the "next" run and the Debug page is showing theDebugNewRelevantRunBar
, it does not need to perform the cache invalidation because the front end has not cached any queries. Currently, this use case causes the Debug page to flash the loading skeleton when theDebugNewRelevantRunBar
transitions from the running to completed state. With the refactor in the previous bullet, update the cache invalidation to only happen on a status change when watching thecurrent
run.getRelevantRunSpecs
method are incorrect. They were copy/pasted from theRelevantRunsDataSource
. They should be updated to reflect what this file does.The text was updated successfully, but these errors were encountered: