Update on those enwiki edits: a friendly oversighter (suppress for everyone here) has confirmed that "You have either not specified any target revision on which to perform this function, or the specified revision does not exist, or you are attempting to hide the current revision." appears when they attempt to query if anything's interesting about those edits from an oversighter perspective. I'm not sure how accurate that message is if I got the revid from the revision table! :p

On enwiki, the page IDs for those four edits don't seem to exist in the page table: (query https://quarry.wmcloud.org/query/79659)

SELECT
  *
FROM
  revision_userindex
  LEFT JOIN `page` p ON rev_page = page_id
WHERE
  rev_actor = 75321 AND
  p.page_id IS NULL
ORDER BY rev_timestamp ASC

so it took me a while to notice this, but xtools actually was matching fast-ec if you go by the sum of the "yearly bar graph" chart. unfortunately, that number turns out to be wrong due to SQL whatever, see T325492 edit I mean T355027 for the ongoing investigation (thanks musik for actually doing the work)

Generally the codebase has quite a few unwraps, excepts, indexing operations, etc that all panic a fair amount. Currently these all panic and crash the Tokio thread, so the idea with this task is to make them all bubble up the error and show an error page to the user, instead of panicking. Perhaps this could be done using one of the "standard" Rust crates for the purpose. Those include anyhow, eyre, etc etc.

it's not a good fix but it's a fix

So while the wikipool is waiting for one of the 10 connections to become available, would it be possible to track that time separately? I selfishly would like to display something like "query took 20 seconds, after waiting for an available connection for 30 seconds" in the results page instead of "query took 50 seconds".

https://gitlab.wikimedia.org/toolforge-repos/fast-ec/-/commit/96b34d7b3c0b6501d40ec5fffa7f3f5bc0ee7272

looks nice, but I'm handling multiple wikis, so I would need a different connection string per wiki, which means that pool code wouldn't work, right?

yep, lego's total count is 3 more in xtools vs fast-ec, and mine is 4 more. sorta weird. hopefully not caching?

some options:

sounds good, let's just close it

Just Vector 2022, as you said.

I would like it so that clicking on "Reply" sends one to a help page, such as https://www.mediawiki.org/wiki/Help:DiscussionTools, and that this be accomplished however the MediaWiki people think is sensible.

Ha! huge facepalm Yes, I realize now that when the user doesn't exist, it would be an impossible request. I support improving the error reporting, although surely it's not a very important bug.

@Aayush2492 see https://wikimedia.zulipchat.com/#narrow/stream/314034-gsoc2022.3A-Edit-Request-Wizard

@Ankur0710 The microtasks are supposed to be open-ended. Having reviewed the microtask descriptions just now, I think they're at the right level of detail. I would be happy to add more clarification on particular points if requested.

Woohoo! Thank you!

@Ankur0710 Thanks for your interest in the project! See the task description for tasks.

@AmeyGupta, @NavyaB.10, and @Mohdabbas955, thanks for submitting your microtasks. I request that you delete your comments and PM the links to me on zulip - I've updated the instructions due to changing my mind on whether the microtask submissions should be public. Sorry for the inconvenience.