Change 828080 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/Phonos@master] Catch all PhonosExceptions and render localized errors to user

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

Change 828080 merged by jenkins-bot:

[mediawiki/extensions/Phonos@master] Catch all PhonosExceptions and render localized errors to user

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

Change 829548 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/Phonos@master] Move button error stae from client to server

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

Testing notes

In addition to the cases listed in the description above, here is a wikitext table including lots of different combinations of {{#phonos}} parameters, many of which are invalid: P33787. You can copy and paste this into any article.

Change 829548 merged by jenkins-bot:

[mediawiki/extensions/Phonos@master] Move button error state from client to server

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

@MusikAnimal Please review the below. I don't know if all the error messages are correct. In particular:

• Error message for $wgPhonosApiEndpointLarynx = 'https://example.org';
• Fatal exception for $wgPhonosEngine = "invalid";
• Fatal exception for $wgPhonosFileBackend = "invalid";
• Warning for invalid $wgPhonosWikibaseProperties
• Two case where the category Pages with Phonos rendering errors is not added

Types of fatal errors (for QA purposes)

• When eSpeak fails (i.e. set $wgPhonosEspeak = '/invalid';)

• When Larynx fails (i.e. set $wgPhonosApiEndpointLarynx = 'https://example.org';)

I guess it would be nicer (and more consistent with espeak and google) if the message were instead: Failed to generate audio file using the Larynx engine: Failed to convert audio to MP3...

• When Google fails (i.e. set $wgPhonosApiKeyGoogle = 'foobar';)

• When Lame fails (i.e. set $wgPhonosLame = '/invalid'; – there's actually a unit test for this one)

• When Phonos can't create the storage directory (try changing $wgPhonosPath = '/tmp/directory-with-no-write-permissions'; -- just don't do something that breaks your system)

• When Phonos can't create the file in the storage directory (remove write permissions on the directory)

Acceptance criteria

• All known fatal exceptions should be captured, with localized messages displayed to the user

I am not sure of all the possible fatal exceptions. However, I have tried invalid values for all the Phonos configuration variables in extensions.json:

• If the $wgPhonosEngine is invalid (e.g. $wgPhonosEngine = "invalid";) the page does not load and instead I see an exception:

MediaWiki internal error.

Original exception: [7ce3a6be20e7ac984aa64081] /wiki/Phonos_Natural ConfigException: Invalid is not a valid engine
...

• $wgPhonosApiEndpointGoogle = "http://localhost";
  

• $wgPhonosApiProxy = "http://localhost:1234"; (the exact error I assume depends on which engine you have selected at the time)
  

• $wgPhonosFileBackend = "invalid"; the page does not load and I see the exception:

MediaWiki internal error.

Original exception: [e0da568956e4777dbb9bb5ff] /w/index.php?title=Phonos_Natural&action=submit InvalidArgumentException: No backend defined with the name 'invalid'.
...

• $wgPhonosFileBackendDirectory = "/invalid"; (does vary depending on the exact value)
  

• $wgPhonosWikibaseUrl = "http://localhost";
  

• $wgPhonosWikibaseProperties = ["wikibasePronunciationAudioProp" => "invalid", "wikibaseLangNameProp" => "invalid", "wikibaseIETFLangTagProp" => "invalid"];
  
  It also shows the warning: Warning: Invalid argument supplied for foreach() in /var/www/html/w/extensions/Phonos/includes/Wikibase/WikibaseEntityAndLexemeFetcher.php on line 123

• $wgPhonosCommonsMediaUrl = "http://localhost";
  

• No espeak binary
  

• No lame binary
  

• Place the page in a tracking category called Pages with Phonos rendering errors

Not always. For example, it is not added to that category with the below configurations:

• $wgPhonosCommonsMediaUrl = "http://localhost";
• $wgPhonosPath = '/tmp/directory-with-no-write-permissions';

• Designs use the standard Html::errorBox() as provided my MediaWiki

I guess. It looks like other error boxes I have seen.

• Recoverable errors such as a missing file via file= parameter should not prevent Phonos from outputting the button as usual (as we have user-friendly error messages for that)

I have tried to test some of these. They seem OK.

• Errors are tracked in Statsd, given we're capturing the exceptions thus they won't show up in Logstash (no idea how to QA this, but I followed Extension:Score's example)

Statsd might work in beta, so we can test it there.

Test environment: local docker Phonos 0.1.0 (9600dec) 06:46, 22 September 2022.

In T316700#8281172, @NRodriguez wrote:

I found a truest edgecase, so I am going to mark this as resolved, but if you preview the thing next to the Show Preview box, the z-index is wrong and it will show the warning under the box

...

This also may have been the wrong patchdemo I tested on, anyhow, resolving for now!

Thanks! It is reproducible on beta, so I have raised T320632.

In T316700#8255736, @dom_walden wrote:

@MusikAnimal Please review the below. I don't know if all the error messages are correct. In particular:

• Error message for $wgPhonosApiEndpointLarynx = 'https://example.org';

I have not raised this.

• Fatal exception for $wgPhonosEngine = "invalid";

I have raised T320628.

• Fatal exception for $wgPhonosFileBackend = "invalid";

I have raised T320629.

• Warning for invalid $wgPhonosWikibaseProperties

I have not raised this.

• Two case where the category Pages with Phonos rendering errors is not added

I have raised T320631.

Let me first apologize for my negligence in replying to T316700#8255736! I have changed my Gmail filters so that when I'm pinged, the email goes into my normal inbox instead of the Phab folder, so I shouldn't miss your pings moving forward :)

Everything at T316700#8255736 looks expected to me. I've closed T320628 as that is intentional behaviour. The other two new tasks are valid but not of any large concern as these errors can only happen due to sysadmin misconfiguration.

In T316700#8255736, @dom_walden wrote:

Statsd might work in beta, so we can test it there.

I finally got around to this. I can see some events of the form MediaWiki.extension.Phonos.IPA.error.* being recorded in graphite on beta. For example: https://graphite-labs.wikimedia.org/?width=1611&height=804&from=00%3A00_20221109&until=23%3A59_20221109&target=MediaWiki.extension.Phonos.IPA.error.by_wiki.enwiki.count

We only see raw numbers of errors, rather than any information about the sort of errors being raised. I am guessing this is all the data statsd is designed to record.