Conversation
Replace misspelled parameter `verifiedd_flags_list` with the correct `verified_flags_list` in QcFlagRepository.
Remove incorrect/duplicated identifier `verifiedd_flags_list` from the destructuring and mapping in QcFlagRepository.
Add optional runNumber filtering for GAQ summaries. Controller validation and handler accept runNumber query param and pass it to GaqService; GaqService forwards runNumber to QcFlagRepository and unwraps a single-run summary when requested. RunsPerDataPassOverviewModel tracks per-run RemoteData in _gaqSummary$, fetches GAQ summaries for visible runs, and RunsPerDataPassOverviewPage renders loading/success/failure states. These changes enable fetching and displaying GAQ data scoped to individual runs to reduce load and improve UX.
Make GAQ summary fetches run sequentially so to ease reduce load on the database.
…se load Make runNumber a required Joi parameter to prevent user stressing the database fetching data for all runs of a dataPass. Intended to be reverted once database query has been optimised.
Tighten Joi validation for GAQ summary by requiring dataPassId and runNumber to be positive numbers.
Adjust the runsPerDataPass overview test to match updated row and expected GAQ values.
Update qcFlags GAQ summary tests to include runNumber and strengthen request validation coverage.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2071 +/- ##
==========================================
+ Coverage 45.55% 45.62% +0.06%
==========================================
Files 1031 1031
Lines 17196 17249 +53
Branches 3129 3136 +7
==========================================
+ Hits 7834 7870 +36
- Misses 9362 9379 +17 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Use RemoteDataSource and AbortController to make per-run GAQ summary fetches cancelable. Can be easily adapted to use an array of remotedatasources if in the future we decide to request them in parallel.
When updating the GAQ summary for a run, store the actual success payload instead of the raw remoteData object.
Add a test that captures outgoing GAQ summary requests and asserts each run triggers exactly one GAQ request.
| try { | ||
| await this._fetchGaqSummary(runNumber); | ||
| } catch { | ||
| if (signal.aborted) { |
There was a problem hiding this comment.
I'm not sure if this last check is needed. Additionally, you might want to print some kind of warning about the run number that was aborted
There was a problem hiding this comment.
Correct. remoteDataSource will handle any errors internally without re-throwing so we can remove this try/catch.
Regarding printing a warning, the requests will only be aborted when a user does something to remove the table, I.E change page, change pagination etc. I think in these situations the user does not need to know the past data was aborted.
| * @return {Promise<GaqSummary>} Resolves with the GAQ Summary | ||
| */ | ||
| async getSummary(dataPassId, { mcReproducibleAsNotBad = false } = {}) { | ||
| async getSummary(dataPassId, { mcReproducibleAsNotBad = false, runNumber } = {}) { |
There was a problem hiding this comment.
dataPassId is not documented
There was a problem hiding this comment.
Could you elaborate? If you mean in terms of the JSDoc then it is there, at the top.
| * @return {Promise<GaqSummary>} Resolves with the GAQ Summary | ||
| */ | ||
| async getSummary(dataPassId, { mcReproducibleAsNotBad = false } = {}) { | ||
| async getSummary(dataPassId, { mcReproducibleAsNotBad = false, runNumber } = {}) { |
There was a problem hiding this comment.
I suggest you name runNumber something different, to differentiate it from the runNumber you're using in the map function
NarrowsProjects
left a comment
There was a problem hiding this comment.
I'd like you to rename the arguments of getSummary() in GaqService, and i'd like you to reconsider the last signal.aborted check inside _fetchGaqSummaryForCurrentRuns() in RunsPerDataPassOverviewModel
| this._markAsSkimmableRequestResult$ = new ObservableData(RemoteData.notAsked()); | ||
| this._markAsSkimmableRequestResult$.bubbleTo(this); | ||
|
|
||
| this._gaqSummary$ = new ObservableData({}); |
There was a problem hiding this comment.
As you use observable data, you can already tell it what the source to look for is rather than doing it on L82
There was a problem hiding this comment.
I am not sure how to use it with the asynchronous nature of the summaries.
| this._gaqSummary$ = new ObservableData({}); | ||
| this._gaqSummary$.bubbleTo(this); | ||
|
|
||
| this._gaqSummarySource = null; |
There was a problem hiding this comment.
This, implies that all the time we will want a sequence in requests but in reality, as soon as we improve the back-end SQL we will want to have all these in parallel. The proposed code design does not allow that.
I would propose that we start with a parallel design in mind already (e.g. using a Map to keep al sources) so that we can quickly migrate to it afterwards
There was a problem hiding this comment.
Okay, I originally added this because I was doing it in parallel at the start but removed given we thought best to do in sequence for now. I can add back.
I have a JIRA ticket
Notable changes for users:
Notable changes for developers:
Changes made to the database: