Page MenuHomePhabricator

ApiBlock doesn't recognise ipb_already_blocked
Closed, ResolvedPublic

Description

{
"servedby": "xxxxxx",
"error": {

		"code": "unknownerror",
		"info": "Unknown error: ``ipb_already_blocked''"

}
}


Version: unspecified
Severity: trivial

Details

Reference
bz28797

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:32 PM
bzimport set Reference to bz28797.

It's declared in /branches/REL1_17/phase3/includes/api/ApiBase.php so I don't see how this could happen. Are you still seeing this behavior in the 1.17.0b1 release?

No, 1.17 works fine:

{
"servedby": "*",
"error": {

		"code": "alreadyblocked",
		"info": "The user you tried to block was already blocked"

}
}

Then why is this bug in the 1.17.0beta1 component, and which version are you seeing this on? :)

Shaky hands? :) It's on trunk, sorry.

(In reply to comment #4)

Shaky hands? :) It's on trunk, sorry.

A quick glance at trunk seems to indicate this issue /should/ not happen there either (the message is defined in ApiBase.php, grep 'ipb_already_blocked'). I'll try to reproduce it later.

Broken by r83786, as bisect indicates.

happy.melon.wiki wrote:

Fixed in r87627. It was actually a bug in the API which was exposed by r83796, rather than being introduced by it.

(In reply to comment #7)

Fixed in r87627. It was actually a bug in the API which was exposed by r83796,
rather than being introduced by it.

The function you "fixed" doesn't expect nested arrays, and the documentation mentions this (even if in passing; it says it expects and *element* of a nested errors array), so whatever was feeding it nested arrays was at fault. The array_shift()ing was done by the callers.

Either way, it's probably cleaner to make the de-nesting the responsibility of parseMsg() like you did.