I am working on FileAnnotations’ error handling. When I started writing the patch I wasn’t aware of all the cases we’ll have to tackle, Mark was nice enough to guide. Below is a list of errors that could occur and how to handle them.

AbuseFilter
AbuseFilter does not reject the mw.Api promise, but returns an object that has a warning.

{
  "edit": {
    "code": "abusefilter-disallowed",
    "message": {
      "key": "abusefilter-disallowed",
      "params": [
        "Test filter",
        2
      ]
    },
    "abusefilter": {
      "id": 2,
      "description": "Test filter",
      "actions": [
        "disallow"
      ]
    },
    "info": "Hit AbuseFilter: Test filter",
    "warning": "This action has been automatically identified as harmful, and therefore disallowed.\nIf you believe your action was constructive, please inform an administrator of what you were trying to do.\nA brief description of the abuse rule which your action matched is: Test filter",
    "result": "Failure"
  }
}

Use the abusefilter-disallowed message here.

No edit permission
This one rejects the promise and the function has the error code as a string and an object literal that has details. It has the same object again as the third argument, I wonder what that is about.

{
  "error": {
    "code": "permissiondenied",
    "info": "The \"permissiondenied\" right is required to edit this page",
    "*": "See http://localhost:8080/w/api.php for API usage"
  }
}

Should probably not show the add annotation interface if the user does not have permissions in the first place. In case we do, use the permissionserror message from core.

Session expired
Tested a few cases for this. If the user is logged out in the middle of adding an annotation they’d get a permissiondenied error. But if one logs out and logs into a different account in another tab, the new edit is correctly attributed to the newly logged in account.

Unreachable server
I found the api-error-http error message but haven’t been able to figure out how or when it triggers. Have filed a separate task for now.

Block
This rejects the promise with error messages too. Could show api-error-blocked here, but it doesn’t show some of the useful information that is returned.

{
  "error": {
    "code": "blocked",
    "info": "You have been blocked from editing",
    "blockinfo": {
      "blockid": 1,
      "blockedby": "Admin",
      "blockedbyid": 1,
      "blockreason": "",
      "blockedtimestamp": "2016-09-27T20:25:49Z",
      "blockexpiry": "2016-09-27T22:25:49Z"
    },
    "*": "See http://localhost:8080/w/api.php for API usage"
  }
}

Protected page
Should protecting a File page automatically protect the Annotations page too? This is the same as some of the other errors, and core already has a protectedpage message.

{
  "error": {
    "code": "protectedpage",
    "info": "The \"editprotected\" right is required to edit this page",
    "*": "See http://localhost:8080/w/api.php for API usage"
  }
}

Looking at all the api-error-* messages in core, these might show up too.

• autoblock
• badtoken
• http (timeout error?)
• timeout
• unclassified

Here is the updated patch.