The Android user contribution screen schema (legacy, MEP) contains an action value of ip_block. The field description in the MEP schema states that the event is generated when a user's IP address is blocked. However, upon looking at the instrumentation code, it appears that the event actually corresponds to an application-level user block in MediaWiki. To avoid confusion, the action name should be updated to user_blocked or similar, the description should be updated, and the related method names in the instrumentation code should be updated accordingly.
Description
Description
Related Objects
Related Objects
- Mentioned In
- T228179: Event Platform Client — Android
- Mentioned Here
- T281189: Suggested Edits screen may erroneously show "IP blocked" message
Event Timeline
Comment Actions
@Ottomata Is it permissible to remove an enum value (here, ip_block) from a schema, or does that break the no-backwards-incompatible-changes rule?
Comment Actions
Pretty sure it should be fine, IIUC the enum is only used by the JSONSchema validation; on the Hive side it is just a string.
Comment Actions
Thanks @Ottomata!
OK, I think I see why this is called ip_block. Currently, it can be generated at two different points after the Suggested Edits screen is launched: first, if the user is not logged in, userinfo is queried, and the feature enters "blocked" state (and an ip_block event is logged) if userinfo shows that the (anon IP) account is blocked. If the (anon IP) account is not blocked, the user is prompted to create an account. An ip_block event can also be logged when Wikidata and Commons are queried for the user's contribution stats after ensuring that the user is logged in. I still think that the name ip_block is confusing, because in both cases, what's blocked is actually a MediaWiki user account. In the first case, it happens to be the anon account associated with the user's current IP address. In the second, it probably is not an anon IP account and has nothing to do with the user's IP address.
For what it's worth, I'm also not sure that entering a "blocked" state is desirable just because the anon account associated with the user's current IP address is blocked. For example, it could be blocked for no fault of the user's if the user is on a VPN or using a public access point. And even if the anon IP account is blocked because of the user, we might expect the user to behave better when not editing anonymously.
Comment Actions
I filed T281189 about this. I suspect that this behavior also accounts for the suspiciously large number of ip_block events currently being issued.
Comment Actions
There was a trial fix for the ip_block issues which seems to have fixed it to a certain point. However, since there are still discrepancies between legacy and MEP overall [not just ip
_block], we are choosing a heavier traffic schema to determine if the margin of error is acceptable. So closing this one in favor of T286000