[02:50:07] sup [02:50:13] bye [08:15:48] !log tools clear grid error state from tools-sgeexec-0907, tools-sgeexec-0916, tools-sgeexec-0940 [08:15:52] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [12:54:45] !log tools.pbbot Deploy 78226e6: add MissingPlwikinewsRefsOnPlwiki servlet [12:54:47] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.pbbot/SAL [20:48:28] bd808: hi, got a minute? [21:53:37] RhinosF1: I wouldn't know, the instance is the webservice [21:54:39] Skynet: you can access Api.php from the same IP though? [21:55:24] Perhaps. [21:55:31] Maybe? [21:56:07] It's highly random. It happens in batches it seems suggesting some sort of transient issue at times. [21:56:30] Can you try it when it does happen [21:57:24] I have NEVER been able to reproduce the problem on my end. Presumably because I'm a sysop and have IP Block exempt bundled in. [21:58:36] Can you not just curl it logged out though or something from terminal [21:58:41] The tool will pass back full request details ad-verbatim for error reporting purposes. [21:59:06] What good will that do. I will always get a blocked error message in that case. [21:59:06] Like the full headers is all I want to see so I can make sure we're not missing a block id or anything [21:59:36] Because I want to try and make sure nothing was missed that's useful info [21:59:56] I'm so confused. [22:00:19] I'd expect it to give a block id somehwere in the response [22:00:27] CURLing and action=edit request from a soft-blocked IP will have the intended blocked error message. [22:00:48] Yes and hopefully give you an autoblock id or block id [22:01:01] If it's an autoblock id we can see what actually got blocked [22:01:38] I doubt that actually, but I can certainly try, but I have to ask, can't you make that same test request yourself? [22:02:00] I've never used IA Bot [22:02:19] You're asking me to submit an action=edit request. [22:02:21] I'm just trying to work out what might make the api spit out useful info [22:02:34] From inside a cloud vps terminal [22:02:36] Something from the terminal while logged out. [22:02:48] Seems like you could do that too. [22:03:10] I don't have access to your cloud vps instance though [22:03:23] You don't need to. This is Toolforge [22:03:48] My Cloud VPS's IP has had 0 issues with requests to the API [22:03:54] Then probably if I'm around [22:04:09] * Skynet is eating dinner right now [22:04:14] But as you say it's random so we don't know when it'll happen [22:04:44] I'm doing college work [22:04:48] Exactly, so I'm curious why an attempted anon-edit would be useful. That will trigger a blocked error, which is expected./ [22:05:12] I'm just trying to get the response data so I can get an autoblock id [22:05:21] Which on wiki definately gives so I'd hope the api does [22:06:00] I think autoblock IDs are only associated to user accounts as a consequence of logging into with an IP belonging to a blocked user. [22:06:30] The block message should tell you an id that links back to the block [22:06:55] An autoblock would give you normally your IP was used by xxx [22:06:58] I'll try, but an internal software block doesn't carry an ID I believe [22:07:27] The system ones are soft but that's another point [22:07:44] My plan won't work because they might act before whichever is affecting users [22:07:46] They don't [22:09:13] It [22:09:18] It's not going to work. [22:09:22] $ curl ifconfig.me [22:09:22] 185.15.56.48 [22:09:31] Not even the IP causing trouble. [22:09:44] From within the IABot tool [22:10:00] Skynet: do you have the full response from the api you got for one of the failed requests a user made? [22:10:07] No [22:10:19] Can you get them [22:10:20] I don't log what I don't have to log for privacy. [22:10:47] ... [22:10:57] Without a block ID it's impossible to trace the block [22:11:09] It's not the system ones because they wouldn't be random and are soft [22:11:43] I don't have that info [22:11:51] IABot doesn't log API requests. [22:12:49] I will be putting out an update that passes complete request data back on a failure. [22:12:51] And response [22:13:01] Ok [22:13:06] The user afflicted by the issue can then relay that to the ticket,. [22:13:15] Good idea