Catching any exception like that and replacing it with a generic permission denied seems like a bad idea.

I wish there was a better way to make an edit on behalf of a user with all the permission checks etc. This checks permissions, but I don't think it would check AbuseFilter for example. The only way that I'm aware of that does everything correctly is making an internal API call to ApiEditPage.

Catching any exception like that and replacing it with a generic permission denied seems like a bad idea.

That's fair. It looks like the exception is only thrown for an invalid rigor parameter in getPermissionErrorsInternal so I'm removing that try/catch.

Looking into ApiEditPage now.

This version runs EditFilterMergedContent hook; the same awkward implementation pattern from ApiEditPage and SpecialChangeContentModel is used. I've tested this patch with AbuseFilter, site-wide block, and partial block for a specific title.

Patch was deployed to production at 20:36 UTC; now in Gerrit as https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/507201

Change 507201 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] QuestionPoster: Check permissions and EditFilterMergedContent hook

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

Change 507203 had a related patch set uploaded (by Catrope; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@wmf/1.34.0-wmf.1] QuestionPoster: Check permissions and EditFilterMergedContent hook

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

Change 507203 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.34.0-wmf.1] QuestionPoster: Check permissions and EditFilterMergedContent hook

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

Technically, it works. I can't post a question. Do we want users to get such nothing-telling error message?

Maybe we should display help pane without "ask a question" capability for blocked users? So they can search help on-wiki, but not edit by asking questions?

Right, improved error handling would be nice, but not in scope of yesterday's quick fix. @Urbanecm could you please file a new issue for improved error handling and tag with GrowthExperiments-Help panel ? Thanks!

In case when an edit hits Abuse filter there will be the same message as in @Urbanecm comment. For an edit that hit Abuse filter on a normal page, the message is much more specific:

In T222014#5147165, @kostajh wrote:

Right, improved error handling would be nice, but not in scope of yesterday's quick fix. @Urbanecm could you please file a new issue for improved error handling and tag with GrowthExperiments-Help panel ? Thanks!

Certainly, filled as T222201.

In T222014#5147635, @Etonkovidova wrote:

In case when an edit hits Abuse filter there will be the same message as in @Urbanecm comment. For an edit that hit Abuse filter on a normal page, the message is much more specific:

Filled that part as T222204. Note the error message is (can be) filter-specific.

In T222014#5144326, @Catrope wrote:

The only way that I'm aware of that does everything correctly is making an internal API call to ApiEditPage.

Note that making internal calls like that is a "code smell", though. I started trying to abstract the business logic of it from the API "front-end" in gerrit:460436, but priorities and team assignments changed and I haven't had time to work on it for a while.

In T222014#5210597, @Anomie wrote:

Note that making internal calls like that is a "code smell", though. I started trying to abstract the business logic of it from the API "front-end" in gerrit:460436, but priorities and team assignments changed and I haven't had time to work on it for a while.

Completely agreed. It'd be great to have something that isn't as code-smelly as doing an internal API call and also doesn't skip half the steps we need, and it looks like your EditController class would be that.