Status Update
Comments
ek...@google.com <ek...@google.com> #2
IIUC this info is pro-actively retrieved so that it's already available when the user selects any changes for bulk operations.
What's the issue with the load that this is causing? Isn't it just another change query like any other change query.
Please unassign after replying so that this goes back into our triage queue.
lu...@gmail.com <lu...@gmail.com> #3
What's the issue with the load that this is causing? Isn't it just another change query like any other change query.
It may take some time to complete on the backend and, if the executing time is too long, the browser will keep on running it continuously, generating even more workload.
I can see that on my user the query was run by the browser to the backend 15 times. Having all the users calling this query 15 times every time they visit the list of changes is definitely significant.
ek...@google.com <ek...@google.com> #4
lu...@gmail.com <lu...@gmail.com> #5
It looks like the query with the 100s of OR is performed also for anonymous browsing, which is illogical: how can an anonymous browsing user trigger any block action?
ap...@google.com <ap...@google.com> #6
Project: gerrit
Branch: master
Author: Jacek Centkowski <
Link:
Don't sync bulk actions for anonymous user
Expand for full commit details
Don't sync bulk actions for anonymous user
There is no point in getting additional change details for bulk actions
for an anonymous user as bulk actions componenets are not shown in this
mode anyway. When user logs in list of changes will be refreshed anyway
an then details for bulk actions will be loaded.
Bug: Issue 365254275
Release-Notes: Don't sync bulk actions details for anonymous user.
Change-Id: I9b09991289a5ea555252c9f54a320c993e66e2e1
Files:
- M
polygerrit-ui/app/elements/change-list/gr-change-list-section/gr-change-list-section.ts
Hash: e7a95cc7e132a1b814f72faaa823db976345ec66
Date: Mon Oct 07 10:19:52 2024
ap...@google.com <ap...@google.com> #7
Project: gerrit
Branch: master
Author: Jacek Centkowski <
Link:
Re-use SUBMIT_REQUIREMENTS
in bulk actions sync
Expand for full commit details
Re-use `SUBMIT_REQUIREMENTS` in bulk actions sync
When bulk actions sync is called for `ChangeInfo[]` then query for
`SUBMIT_REQUIREMENTS` bit only in case when not already queried.
In my local setup it brings the following improvements:
cold(s) hot(s) payload(bytes)
HEAD 13.76 10.63 - 10.48 456209
I2645fde 12.80 10.56 - 10.14 386709
Performance wise not much, but it reduces payload by ~15% for default
submit requirements. It will be more evident for more sophisticated
setups.
Bug: Issue 365254275
Release-Notes: Reduce bulk action query result payload by not getting already available SUBMIT_REQUIREMENTS data.
Change-Id: I2645fde56fa0879fee76a0cefaa7cddd7ff695c5
Files:
- M
polygerrit-ui/app/models/bulk-actions/bulk-actions-model.ts
- M
polygerrit-ui/app/models/bulk-actions/bulk-actions-model_test.ts
- M
polygerrit-ui/app/services/gr-rest-api/gr-rest-api-impl.ts
- M
polygerrit-ui/app/services/gr-rest-api/gr-rest-api-impl_test.ts
- M
polygerrit-ui/app/services/gr-rest-api/gr-rest-api.ts
- M
polygerrit-ui/app/test/mocks/gr-rest-api_mock.ts
Hash: dd928132285c23948d4ca33ad3b837c720ed69f3
Date: Sun Dec 29 17:41:27 2024
Description
Affected Version: 3.10 (possibly also earlier versions)
What steps will reproduce the problem?
What is the expected output?
The list of changes should trigger a query for open changes
https://gerrit-review.googlesource.com/changes/?O=5000081&S=0&n=100&q=status%3Aopen&allow-incomplete-results=true
What do you see instead?
In addition to the above query you see the following one:
https://gerrit-review.googlesource.com/changes/?O=1010102&S=0&q=change%3A436677%20OR%20change%3A425398%20OR%20change%3A433239%20OR%20change%3A433240%20OR%20change%3A433238%20OR%20change%3A431917%20OR%20change%3A435877%20OR%20change%3A436558%20OR%20change%3A436557%20OR%20change%3A436517%20OR%20change%3A436597%20OR%20change%3A436537%20OR%20change%3A436277%20OR%20change%3A436258%20OR%20change%3A436477%20OR%20change%3A436257%20OR%20change%3A436259%20OR%20change%3A436260%20OR%20change%3A436418%20OR%20change%3A436417%20OR%20change%3A436457%20OR%20change%3A436397%20OR%20change%3A436437%20OR%20change%3A436399%20OR%20change%3A436398%20OR%20change%3A432279%20OR%20change%3A436377%20OR%20change%3A246495%20OR%20change%3A436357%20OR%20change%3A375726%20OR%20change%3A425521%20OR%20change%3A436337%20OR%20change%3A375374%20OR%20change%3A434998%20OR%20change%3A434997%20OR%20change%3A436237%20OR%20change%3A435078%20OR%20change%3A436239%20OR%20change%3A435399%20OR%20change%3A435998%20OR%20change%3A435957%20OR%20change%3A429518%20OR%20change%3A436097%20OR%20change%3A434699%20OR%20change%3A434698%20OR%20change%3A434697%20OR%20change%3A424298%20OR%20change%3A425505%20OR%20change%3A424300%20OR%20change%3A433998%20OR%20change%3A425522%20OR%20change%3A424299%20OR%20change%3A434237%20OR%20change%3A433997%20OR%20change%3A434297%20OR%20change%3A425917%20OR%20change%3A434298%20OR%20change%3A433999%20OR%20change%3A436039%20OR%20change%3A436037%20OR%20change%3A435018%20OR%20change%3A405457%20OR%20change%3A338837%20OR%20change%3A434797%20OR%20change%3A434798%20OR%20change%3A435338%20OR%20change%3A435297%20OR%20change%3A435677%20OR%20change%3A432097%20OR%20change%3A418881%20OR%20change%3A435337%20OR%20change%3A435857%20OR%20change%3A435917%20OR%20change%3A247442%20OR%20change%3A247054%20OR%20change%3A433477%20OR%20change%3A432277%20OR%20change%3A435578%20OR%20change%3A435537%20OR%20change%3A409722%20OR%20change%3A404437%20OR%20change%3A435318%20OR%20change%3A435317%20OR%20change%3A377074%20OR%20change%3A434557%20OR%20change%3A434897%20OR%20change%3A435237%20OR%20change%3A435217%20OR%20change%3A435197%20OR%20change%3A434999%20OR%20change%3A424580%20OR%20change%3A424039%20OR%20change%3A424577%20OR%20change%3A339338%20OR%20change%3A435137%20OR%20change%3A366336%20OR%20change%3A358180%20OR%20change%3A434157%20OR%20change%3A434589%20OR%20change%3A434837&allow-incomplete-results=true
What is the output of the JS console log (if applicable)?
Nothing relevant.
What is the performance record (seehttps://developers.google.com/web/tools /chrome-devtools/evaluate-performance/reference#record)(if applicable)?
Nothing relevant.
Please provide any additional information below.
Looks like the new mechanism was introduced for refreshing the status changes impacted by bulk actions (seehttps://gerrit-review.googlesource.com/c/gerrit/+/329492 ) and the feature flag is now enabled by default (see https://gerrit-review.googlesource.com/c/gerrit/+/345229 ). What I do not get is why this is triggered also when there is no intention to run any bulk action.