Is there a reason you need to do this?

Now that I've understood what's going on, and adjusted my bot to compensate, no, but it was an unexpected point of failure, and the error message was uniquely unhelpful in figuring out the real problem.

According to the API:Login page, you should verify that you're a user by using assert=user. I dislike that method, because it only asserts that you're *a* user, not the *correct* user. So, naturally, I check the user info to make sure that I'm logged in as the correct user. Since I'm logging in as RobinHood70@RobinHood70Bot, I naturally checked for that to be the username, and it wasn't (being only RobinHood70). So, naturally, I attempted to re-login and it failed. The reason returned only told me that I couldn't log in, but didn't tell me anything useful about why not.

At the very least, we need a more descriptive error message, but I really don't think attempting to log in twice with the same (valid) credentials should constitute an error. It never has before, and it's unintuitive that it would.

In T154324#2907515, @RobinHood70 wrote:

According to the API:Login page, you should verify that you're a user by using assert=user. I dislike that method, because it only asserts that you're *a* user, not the *correct* user.

Since 1.28.0-wmf.22 there's an assertuser parameter to allow you to assert that you're logged in as a specific user. See T146770: Add assertuser=Whomever to the API, to prevent accidentally performing requests as the wrong user and rMWfec31a8b9d2a: API: Add assertuser parameter.

At the very least, we need a more descriptive error message, but I really don't think attempting to log in twice with the same (valid) credentials should constitute an error. It never has before, and it's unintuitive that it would.

As for potentially fixing this, the tricky part is that the BotPasswords session intentionally can't handle changing users so it would need to throw the error later on if you try to use the deprecated main-account-login code path, but it can't easily differentiate that from the bot-password code path when a wrong password is supplied. A different error message would be easy enough to do if someone wants to.

Good to know. Thanks for putting me onto that; at some point in the future, I'll likely strip out all the coding for older versions and add features like assertuser in their place. At the moment, it does me no good, though, since most of the sites I'm targetting are using anywhere between 1.19 to 1.26. Outside MediaWiki sites themselves, I rarely come across sites that are on 1.28+.

In T154324#2907447, @Anomie wrote:

Is there a reason you need to do this?

I find myself sometimes in need to use the delete.py script using my sysop account, and I keep logged it on the web sesion because I want to check what I am doing in real-time.

In T154324#4163280, @MarcoAurelio wrote:

In T154324#2907447, @Anomie wrote:

Is there a reason you need to do this?

I find myself sometimes in need to use the delete.py script using my sysop account, and I keep logged it on the web sesion because I want to check what I am doing in real-time.

Running delete.py while being logged in in your browser too is not the issue here. The issue here would be if delete.py is trying to log in when delete.py itself is already logged in.