Last modified: 2013-04-18 22:18:25 UTC
Cloning this from bug 43701 (with particular focus on bug 43701 comment 14): --- This is going to be a bit difficult to fix. The LinksUpdateAfterInsert hook doesn't provide any access to the agent, nor does the function that calls the hook, LinkUpdate::incrTableUpdate. I imagine the agent is abandoned further up the chain somewhere. The way we're retrieving the agent right now is just through the global $wgUser, which isn't reliable. I see 4 possible solutions: 1. pass the agent all the way through the chain from the article being saved to the hook being executed (might be a pain) 2. Figure out how to get the jobqueue to properly set $wgUser for every action it performs (probably a pain) 3. Don't include the agent in this notification. It's not really important in this context anyway, which is why it isn't in the execution chain. Why would a user care who performed the linking? 4. Don't include the agent in the notification if the agent is the jobqueue (127.0.0.1). This will be a bit of a pain since we'll have to create a separate notification type for this one edge case (since all the messages will need to be different). --- Bug 43701 seems to have been worked around (the relevant messages were rewritten, effectively option 3), but I think the underlying issue is still unresolved. Filing a new bug so this doesn't get lost, if there's still an issue. If there's no longer an issue, feel free to mark this resolved.
Since no one is actually needing an agent param from the LinksUpdateAfterInsert hook currently (the designer removed it from the message without even knowing about the bug), I would hate to bloat the core code to facilitate such a parameter. I looked at the other hooks we're using and it looks like there is a similar issue with the UserRights hook. In this case we are actually using the agent in the notification message, and it is possible (though rare) for user rights to be changed via the API. Question: Are all API requests handled by the job queue or only editing requests?
(In reply to comment #1) > Question: Are all API requests handled by the job queue or only editing > requests? I'm not sure I understand what you're asking. As far as I know, all API requests are not handled by the job queue (including edits). Specific actions performed via the API (edit, delete, etc.) may trigger the creation of jobs (adding to the size of the job queue), but all requests are served by the API cluster as soon as possible and the API cluster is almost always up-to-date (though occasionally a slave will lag by a few thousands seconds).
I guess my real question then is, does changing a person's user groups ever create a job? (In which case using the $wgUser global would be unreliable.) I would imagine not, as it's a trivial db update.
Having a hard time finding anything I can actually fix for this bug, as we don't want to add new hook params unless they are actually needed, and I don't think it's a good idea to build a lot of extra context passing in core unless we need it. While it's true it might to useful to someone in the future, "If it ain't broke, don't fix it." Going to resolve this bug for now. You could theoretically file a bug about getting the jobqueue to properly set $wgUser for every action it performs, but I'm not sure if that's likely to get much traction. In the meantime, I can't find anything in Echo that is actually affected by this potential issue.
