Open Technical-13 opened 11 years ago
@theopolisme:
this was removed in the _setup or so before _cleanup() is run.
I will check what we have to do to fix that...
Can you try cleaning up https://test.wikipedia.org/wiki/Wikipedia_talk:Articles_for_creation/theo_sandbox (by pasting the latest core.js and submissions.js into your browser -- it's a pain, I know) and letting me know whether or not the error message is displayed? I'm trying to isolate the issue but I can't replicate it on my end.
Just update my common.js on test and I'll run it... I'm too pooped to do much of anything tonight... I just want to go to bed early.
@Technical-13 done, click the bottom review link.
Could not replicate. @Technical-13 if you don't encounter this again in the next few days I'm inclined to close it as a MediaWiki API temporary problem rather than anything on our end.
I'm seeing it more and more. Just saw it declining a submission again.
We should look and see what specifically mw.api() is returning as the .fail() contents...
@Technical-13: Are you seeing specifically the "http" error more and more, or the "editconflict" error as described in #194?
both, but not at same time.
@Technical-13:
I wish I could replicate this. Please screenshot the next time it happens and give me as many details as possible.
I've modified the error logging to display more information in this commit. Once it is pushed to beta we'll hopefully have some more information about the problem. Or, alternatively, @Technical-13, just use the develop script (if you have the time of course).
Until this is resolved, though, I don't want to release a new master build.
@theopolisme part of the problem was error messages being overwritten, so I've gone through and added console.error logging for now under the error messages so the error messages will be easy to find even if overwritten. It probably wouldn't hurt to leave those console logging features there, since they should only occur if there are errors.
Good idea, but flawed implementation..console
should never be used in production or anything going out to users. You say the error messages are being "overwritten"? What?? Could you elaborate on that? Based on our current system that seems impossible...
Alright, I've reinstated the console.error() but with an additional safeguard in place to avoid a reference error in a browser that does not support console
.
I wasn't putting the console.error in production, just in develop so that I could test it. I was going to do some testing tonight, but due to #202 the script isn't running at all right now...
@Technical-13 any console.error()s for us to look at? Not to rush you; real life > wikipedia :)
I've been real tied up in real life recently, and have only had a chance to review/clean a dozen or so submissions, which haven't produced any errors. I'm super busy with school and housing and such until at least Wednesday, but will try to poke at a few more submissions and see if I can turn up anything.
Will close as could not reproduce (xkcd for the win) in a week or so if no further reports.
@theopolisme I think, we should try to get morebits in and try to get AFCH /slowly/ as a predefined modul... well I don't find it any more (was it FURME or in the TWINKLE code itself or was it morebits, dunno) at least /somewhere/ there was an explanation about an array(?) which should be mostly empty (for the case there aren't any user defined moduls... hell the furme integration work was simply too long ago)
TL;DR: do we want to rely on morebits (ie8+) or doing our own soup? (mmmh, is this a known phrase in English?)