The answer looks to be:

This appears to have regressed, I just minted the folllowing URL which mastodon and Derk-Jan / @TheDJ@mastodon.social asked me to bring the issue to phabricator.

@Aklapper that banner requests page assumes that (a) that I'm the one running the campaign and (b) that the campaign is for a particular known-in-advance time. Neither are true here.
This also does not obviously match any of contact points in the Trust and Safety page as far as I can tell.

The issues I was seeing previously appear to have all resolved themselves, thank you.

I'm seeing failures of URLs like https://orcid-scraper.toolforge.org/results?qid=Q112671057

Just got a different message from https://author-disambiguator.toolforge.org/names_oauth.php?... . This may be a result of a DNS failure not being caught?
`
Warning: Undefined variable $http_response_header in /data/project/author-disambiguator/public_html/lib/borrowed_utilities.php on line 41`

I've opened a superset discussion at https://github.com/apache/superset/discussions/24455 related to getting superset to export wikitables.

In T169452#8945111, @rook wrote:

In T169452#8945074, @Stuartyeates wrote:

In T169452#8938537, @rook wrote:

In T169452#8936883, @Stuartyeates wrote:

I'm aware that our superset install doesn't currently do caching of resultsets, but there is documentation in the superset docs related to caching at https://superset.apache.org/docs/installation/cache/ Is this caching something other than resultsets?

I previously got this deployed in the docker environment. Though so far as I could tell it was only for caching chart query results. Rather than sql lab results. I have not observed caching working for sql lab queries.

In T169452#8936916, @Stuartyeates wrote:

My understanding is that the current https://superset.wmcloud.org/ will be retained (with some improvements / tweaks / etc.) and the current https://quarry.wmcloud.org/ will be retained (without significant maintenance).

Over time https://superset.wmcloud.org/ will accrue improvements (both locally and from upstream). Over time https://quarry.wmcloud.org/ will not, falling behind in terms of maintenance and standards until it fails completely.

This is mostly the intention. However there is not the intention to let quarry run until it fails. Rather the intention would be (there is currently no timeline for this), when superset is mostly where we are going to get it, quarry would be set to read only, thus encouraging anyone who hasn't started using superset to copy their queries over and start. The concern is if we let quarry run until it fails, many queries could be lost.

I expect the "Download data" / "wikitable" will almost certainly have to be completely written from one to the other.

This is correct. Indeed anyone so inclined should submit a patch to upstream https://github.com/apache/superset

In T169452#8936664, @Wbm1058 wrote:

I'm making more sense of this, figuring out things that should have been explained to us from the start of this phab.

"Superset" is Apache Superset (see the Wikipedia article). It was created circa 2017, apparently not long before yuvipanda created this task. Wikimedia Toolforge Quarry dates back to at least 2014, so is around three years older than Apache Superset. So yuvipanda couldn't have recommended using Apache Superset in 2014 because it did not yet exist.

I see that both are written in Python, so by "Move Quarry to be an installation of Superset" do you mean you want to move yuvipanda's Python code into the Apache Superset code-set? On the results on my first Apache Superset run I see a button "DOWNLOAD TO CSV"... can we move yuvipanda's Python code for the Quarry "Download data" button (which includes six other options besides CSV) so that yuvipanda's button replaces the "DOWNLOAD TO CSV" button?

I'm aware that our superset install doesn't currently do caching of resultsets, but there is documentation in the superset docs related to caching at https://superset.apache.org/docs/installation/cache/ Is this caching something other than resultsets?

Exactly. These ones are already there, by request or spoken need, and now we are going to lose them.

Third. But, but but... we were told that Quarry "lacks support" and Superset has support overflowing with more support... who is providing this support? They don't even support Wikitable export? You mean Superset isn't really a superset of Quarry?

Do either Quarry or Superset store their data in one of the accessible databases? [i.e. can we write superset queries to evaluate superset or quarry usage?]

My query works again. Thank you, rook.

Superset worked fro me a few days ago, but now I'm just getting https://superset.wmcloud.org/superset/sqllab/

(a) As currently configured, Quarry is much easier to get started in than superset. Maybe we could add hints or some a random get-started query of something?

I think I've just been struck by this bug.