"Edit failed" Error http #177

Open
Technical-13 opened this Issue Sep 23, 2013 · 21 comments

Comments

Projects
None yet
3 participants

@ghost ghost assigned theopolisme Sep 23, 2013

Member

wikipedia-mabdul commented Sep 23, 2013

@theopolisme:

this was removed in the _setup or so before _cleanup() is run.

I will check what we have to do to fix that...

theopolisme added a commit that referenced this issue Sep 23, 2013

Contributor

theopolisme commented Sep 23, 2013

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.

Contributor

Technical-13 commented Sep 23, 2013

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.

Contributor

theopolisme commented Sep 23, 2013

@Technical-13 done, click the bottom review link.

Contributor

theopolisme commented Sep 24, 2013

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.

Contributor

Technical-13 commented Oct 3, 2013

I'm seeing it more and more. Just saw it declining a submission again.

Contributor

theopolisme commented Oct 4, 2013

We should look and see what specifically mw.api() is returning as the .fail() contents...

Contributor

theopolisme commented Oct 6, 2013

@Technical-13: Are you seeing specifically the "http" error more and more, or the "editconflict" error as described in #194?

Contributor

Technical-13 commented Oct 7, 2013

both, but not at same time.

Contributor

theopolisme commented Oct 12, 2013

@Technical-13:

I wish I could replicate this. Please screenshot the next time it happens and give me as many details as possible.

Contributor

theopolisme commented Oct 14, 2013

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.

Contributor

Technical-13 commented Oct 14, 2013

@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.

Contributor

theopolisme commented Oct 14, 2013

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...

Contributor

theopolisme commented Oct 14, 2013

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.

Contributor

Technical-13 commented Oct 16, 2013

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...

Contributor

theopolisme commented Oct 19, 2013

@Technical-13 any console.error()s for us to look at? Not to rush you; real life > wikipedia :)

Contributor

Technical-13 commented Oct 19, 2013

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.

Contributor

theopolisme commented Nov 11, 2013

Will close as could not reproduce (xkcd for the win) in a week or so if no further reports.

Technical-13 referenced this issue in azatoth/twinkle Nov 22, 2013

Fix RFPP for normal users
The current protection data was only read in for sysops

While changing that, removing the old protectionLevel as it was unused
and remove the async nature of the call.
Member

wikipedia-mabdul commented Nov 24, 2013

@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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment