Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Page MenuHomePhabricator

Track outcome of Query Builder queries via embedded query service js
Closed, ResolvedPublic

Description

In T265243, it was investigated how to track the outcomes of the queries made by the Query Builder. It was concluded that using Hadoop would not be ideal, but that we much easier use the embedded query service results view for tracking.

This embedded query service results view has already tracking of its own in ResultView.js.

We want to add tracking for:

  • Query Builder queries that are successful (even if they returned no matches)
  • Query Builder queries that resulted in a timeout
  • Query Builder queries that resulted in any other error

We can use document.referrer to tell referrers apart.

Acceptance criteria:

  • track the referrers based on a list (no-referrer, query-builder-toolforge, other)
  • for each referrer track success results, error and timeouts

Event Timeline

Change 645045 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[wikidata/query/gui@master] Make ResultView.js track based on referrer as well

https://gerrit.wikimedia.org/r/645045

Change 645045 merged by jenkins-bot:
[wikidata/query/gui@master] Make ResultView.js track based on referrer as well

https://gerrit.wikimedia.org/r/645045

This still needs a few things:

  • the change needs to be deployed
  • we need Grafana boards for it

This still needs a few things:

  • the change needs to be deployed
  • we need Grafana boards for it

I was doing it as part of the story itself (maybe a new subtask?) because once the patch is merged we usually call the task (not the story) done.

Mentioned in SAL (#wikimedia-operations) [2020-12-21T08:22:49Z] <dcausse@deploy1001> Started deploy [wdqs/wdqs@512d713]: GUI updates (T269224+i18n updates)

Mentioned in SAL (#wikimedia-operations) [2020-12-21T08:31:46Z] <dcausse@deploy1001> Finished deploy [wdqs/wdqs@512d713]: GUI updates (T269224+i18n updates) (duration: 08m 57s)

Change 654222 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[wikidata/query/gui@master] Check document.URL for query-builder referrer too

https://gerrit.wikimedia.org/r/654222

It got deployed and it seems it didn't work. I investigated and this came up. ^

Ok, then let's try document.URL 👍

If you have a link to share that goes into more detail as to what is available to JS in an iframe, then I would be happy to learn more about it :)

Change 654222 merged by jenkins-bot:
[wikidata/query/gui@master] Check document.URL for query-builder referrer too

https://gerrit.wikimedia.org/r/654222

Change 654228 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[wikidata/query/gui-deploy@production] Merging from 94034f916853b177068051bf86ba942f0f6b618a:

https://gerrit.wikimedia.org/r/654228

Ok, then let's try document.URL 👍

If you have a link to share that goes into more detail as to what is available to JS in an iframe, then I would be happy to learn more about it :)

I don't have phd in iframeology but I have a feeling that js for iframe is being run in the context of the main frame meaning document.URL is needed instead of document.referrer.

Ok, then let's try document.URL 👍

If you have a link to share that goes into more detail as to what is available to JS in an iframe, then I would be happy to learn more about it :)

I don't have phd in iframeology but I have a feeling that js for iframe is being run in the context of the main frame meaning document.URL is needed instead of document.referrer.

🤞

Ok, then let's try document.URL 👍

If you have a link to share that goes into more detail as to what is available to JS in an iframe, then I would be happy to learn more about it :)

I don't have phd in iframeology but I have a feeling that js for iframe is being run in the context of the main frame meaning document.URL is needed instead of document.referrer.

The example at https://developer.mozilla.org/en-US/docs/Web/API/Document/URL#result seems to show that document.URL returns the URL of the inner document, not the top-level window.

The example at https://developer.mozilla.org/en-US/docs/Web/API/Document/URL#result seems to show that document.URL returns the URL of the inner document, not the top-level window.

Ok, so adding document.URL there should not have made any difference. So, maybe the query service UI wasn't actually deployed after we added the code for document.referrer?

Is there a way to check which version of the QueryService UI is deployed in production? For example, can I see the git commit hash somewhere or something similar?

The example at https://developer.mozilla.org/en-US/docs/Web/API/Document/URL#result seems to show that document.URL returns the URL of the inner document, not the top-level window.

Ok, so adding document.URL there should not have made any difference. So, maybe the query service UI wasn't actually deployed after we added the code for document.referrer?

I double checked and we getting data aligns with the second deployment (and not the first).

Is there a way to check which version of the QueryService UI is deployed in production? For example, can I see the git commit hash somewhere or something similar?

Yes, https://github.com/wikimedia/wikidata-query-deploy/commits/master

Is there a way to check which version of the QueryService UI is deployed in production? For example, can I see the git commit hash somewhere or something similar?

Yes, https://github.com/wikimedia/wikidata-query-deploy/commits/master

Well, that doesn’t tell you that much, since the Git author date might be a long time before the commit was actually deployed. Checking the time when something was merged on Gerrit would probably be more representative.

But now that we’re supposed to have faster deployments thanks to microsites, should we try to revert the URL part and see if it affects the data?

Is there a way to check which version of the QueryService UI is deployed in production? For example, can I see the git commit hash somewhere or something similar?

Yes, https://github.com/wikimedia/wikidata-query-deploy/commits/master

Well, that doesn’t tell you that much, since the Git author date might be a long time before the commit was actually deployed. Checking the time when something was merged on Gerrit would probably be more representative.

https://gerrit.wikimedia.org/r/q/project:wikidata/query/deploy but in one or two cases the deployer bypassed gerrit and pushed directly to the repo

But now that we’re supposed to have faster deployments thanks to microsites, should we try to revert the URL part and see if it affects the data?

If @Lydia_Pintscher is fine we potentially lose a day or two of data, I'm fine.

Okay, reverted and deployed. Looks good so far but will keep an eye on it in the next two days.