Page MenuHomePhabricator

Ensure job queued page always shows something
Closed, ResolvedPublic

Description

Sometimes when you start a tally for an election you will see a blank page like this:

image.png (1×2 px, 314 KB)

This is probably because the job finishes before the confirmation page loads. The page is checking for isTallyOngoing which is (presumably) false and therefore nothing gets shown (iirc there is another check that stops any results from loading in this state because at the time the state is expected to happen, the results are now stale).

We should ensure that something shows up in this case. @Prtksxna

Event Timeline

This is probably because the job finishes before the confirmation page loads

So the page thinks that the job is still in the queue or is being tallied? After T287976 is done, would this page be showing the same warning message and buttons as well?

Uh it's more that the job is finished and the page doesn't reflect that

  1. User submits a tally (eg. a 3 vote unencrypted election).
  2. The job got kicked off at the time the user submitted* and because it's small or for whatever reason, it finishes
  3. The page reloads and checks if tally-job-enqueued exists and if it does, it displays the "your job is queued for tallying, please check back later" message
  4. Because the tally is done by the time the page reloads, it shows nothing because tally-job-enqueued returns false

*this is documented behavior - you supposedly get 1 free job w/every web request

There's a check to stop anything besides a hypothetical message from showing up:

		if ( !$form->wasSubmitted() ) {
			$this->showTallyError();
			$this->showTallyResult();
		}

There's another "bug"/"unintended feature" where if you try to refresh the page, it will warn you that you'll resubmit the job which is suboptimal (you probably don't want to re-submit the job). I propose we redirect back to the page (to clear the POST data being sent) which will make the "wasSubmitted" state unnecessary (I think) and resolve this bug along the way. In this case, when you submit the form, it will show you the tally page w/results (if any or from previous tallies) as well as any errors/statuses.

I propose we redirect back to the page (to clear the POST data being sent) which will make the "wasSubmitted" state unnecessary (I think) and resolve this bug along the way. In this case, when you submit the form, it will show you the tally page w/results (if any or from previous tallies) as well as any errors/statuses.

To make sure I understand - when the user hits tally and the job finishes very quickly, we will give them the results instead of giving them a blank page, correct?

I'm proposing that after a user submits a job, we always show the tally page without trying to hide anything (because I don't remember why we hide stuff 😅)

I'm proposing that after a user submits a job, we always show the tally page without trying to hide anything (because I don't remember why we hide stuff 😅)

For this specific example in the task, they will see the results straight away, right?

Yes

Cool. I think it makes sense to show the tally page without hiding anything. The part about us not knowing why we hide stuff makes me a bit suspicious. 🧐

Change 713689 had a related patch set uploaded (by STran; author: Phuedx):

[mediawiki/extensions/SecurePoll@master] tallyPage: Redirect after submitting job

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

Sam's patch resolves this issue. I've gone ahead and associated it w/this ticket.

Change 713689 merged by jenkins-bot:

[mediawiki/extensions/SecurePoll@master] tallyPage: Redirect after submitting job

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

dom_walden subscribed.

After clicking "Create tally", you either see the results immediately or the This election is being (re-)tallied. Please check back later for the results message. You can then refresh the page without it trying to resubmit the tally.

Test Environment: https://vote.wikimedia.beta.wmflabs.org SecurePoll 3.0.0 (a86be99) 06:26, 2 September 2021.