Open nicholas-codecov opened 1 month ago
One thing I can think of is that the “18 successful” text in the image above is going to affected. Since we’re not pulling all uploads, we only have a subset of the data to have that message :confused:. I can't think of a nice way to still have this feature.
This change would also affect the display logic to decide when to show upload vs cff when both are present. Example: let a cff upload with flag "123" be in the first 20 entries and a non-cff upload with flag "123" be item 21 (assume we're paginating by 20 entries) - we'd show the cff entry in the first 20, and when we scroll, we should only show the non-cff upload and get rid of the cff one. I think the proper solution is to handle this on the backend and the frontend only worries about listing uploads, but I recall this being a challenging thing to do in the backend as the filtering logic would need to be written in SQL.
Who isn't always up for a challenge?!
@adrian-codecov we'll need to create four new fields for these eh? Based off of this logic:
function humanReadableOverview(state, count) {
if (state === UploadStateEnum.error) return 'errored'
if (state === UploadStateEnum.processed) return 'successful'
if (state === UploadStateEnum.complete) return 'carried forward'
if (state === UploadStateEnum.started) return 'started'
}
Currently when we fetch a list of uploads for the
UploadsCard
on the commits page, we fetch them as part of theuseCommit
hook, without paginating them. This becomes a problem if a user has a lot of carry forward flags than this list can be thousands of entries which fetching all at once is not optimal.To break down this work a bit more, I'd recommend duplicating the current
useUploads
hook, and implementing the new features, so that they can be broken into multiple PRs.