Apache Allura™

• Description has changed:

Diff:

--- old
+++ new
@@ -1,3 +1,4 @@
+Ref: [allura:tickets:#4454]

 keithmarshall:
 >>>Within the browser view of a ticket, I'll select the "reply" option in one of the follow-up comment panes. I'll enter my reply, in the input pane which is presented. When I subsequently select the "post reply" option, it's a complete lottery as to whether the reply will actually be posted; all too frequently, the system records an edit to the original message, (in which I've changed nothing), while dropping the actual reply on the floor, whence it vanishes into oblivion.

Originally by: keithmarshall

Yep. That link shows me the result of my second attempt to post the "There are two separate ..." reply item; the first attempt, a minute or so before the successful one, resulted in the "Last edit: Keith Marshall x hours ago" annotation on the parent. (Right now, x is 2).

Originally by: keithmarshall

And, it's just done it again, with https://sourceforge.net/p/mingw/bugs/1973/#e713/0c60

• labels: support, p2 --> support, p2, 42cc
• Milestone: limbo --> forge-backlog

I've seen this regularly too. Maybe 5% of my comment replies do it. Perhaps it has something to do with a page being open for a while before entering my comment, but that seems unlikely since the antispam timeout is many hours now.

Originally by: keithmarshall

Another occurrence: posting a top level response to

https://sourceforge.net/p/mingw/bugs/1991/

took me to

https://sourceforge.net/p/mingw/bugs/_discuss/thread/71e5a644/post

with title "(no subject)", and showing "Page 1.0 of 1.24". The message was not posted; it disappeared into the ether. A subsequent retry was successful.

Originally by: keithmarshall

And again, with the preceding response to this ticket; took me to

https://sourceforge.net/p/allura/tickets/_discuss/thread/19773133/post

this time with "(no subject)" and "Page 1.0 of 1.2".

Thanks for the info Keith. When you describe being redirect to a /_discuss/ URL, that sounds like an issue with our anti-spam techniques on forms, which is a different issue than this one (returning to the same page and the parent comment getting an "edited" annotation). I'd make sure you don't leave a page open for more than 24 hours, and have cookies enabled. You can get more help at https://sourceforge.net/support if you continue to get sent to the /_discuss/ urls.

Originally by: keithmarshall

Thanks, Dave.

The redirect from the MinGW ticket certainly wasn't due to the page having been open for more than 24 hours; it occurred less than an hour from the time of ticket creation, and within 10 minutes of me first accessing the page.

OTOH, the redirect from this ticket itself followed a Firefox session restore (today) of a page originally opened on Friday; I did refresh the page, immediately before entering the info, and I do have cookies enabled.

Originally by: keithmarshall

One further curiosity: first attempt to post the preceding reply raised a 403 exception, reporting "Moderate access required"; immediate retry succeeded.

• status: open --> in-progress

Created #380: [#6381] Allura tickets system intermittently discards replies to comments (4cp)

I was not able to reproduce that on a sandbox instance. Can you provide logs around that time frame? Or maybe you have another ideas why this is happening and how to reproduce that? Thanks.

Originally by: keithmarshall

I said it was intermittent; I've no idea how to reliably reproduce it. However, on https://sourceforge.net/p/mingw/bugs/1995/ just now, I tried to reply to Earnie, with an embedded attachment of tchar.h-20130625-2.diff; the text of my reply vanished without trace, leaving my attachment embedded within his earlier post, (and I can't detach it).

I subsequently reinstated my own reply, with it appearing as a top-level discussion item.

Here's data from Keith's recent example on https://sourceforge.net/p/mingw/bugs/1995/ in which he replied to Earnie's "Can you point out" and it ended up as an "edit".

That single post has data:

db.post.find({slug:'3193/08d1'}).pretty()
{
    "_id" : "2ea605ffa93193e59c9130e6e9f157173a07ef97.bugs@mingw.p.sourceforge.net",
    "import_id" : null,
    "status" : "ok",
    "spam_check_id" : "",
    "tool_version" : {
        "tickets" : "0.0"
    },
    "deleted" : false,
    "text" : "Can you point out the non white space changes?  Attaching a diff ignoring the white space changes would be good.",
    "labels" : [ ],
    "app_id" : ObjectId("50f7f9625fcbc91a25ddb92f"),
    "thread_id" : "5b408c28",
    "discussion_id" : ObjectId("50f7f9625fcbc91a25ddb931"),
    "mod_date" : ISODate("2013-06-25T13:14:12.696Z"),
    "app_config_id" : ObjectId("50f7f9625fcbc91a25ddb92f"),
    "last_edit_date" : ISODate("2013-06-25T13:14:12.495Z"),
    "slug" : "3193/08d1",
    "flagged_by" : [ ],
    "edit_count" : 1,
    "last_edit_by_id" : ObjectId("4c66c1790594ca4a13000018"),
    "acl" : [
        {
            "access" : "ALLOW",
            "role_id" : ObjectId("50f7f8e95fcbc91a25ddb34b"),
            "permission" : "moderate"
        }
    ],
    "parent_id" : "ea4c520053ab111c9ca50dc1541abf4a5dec7423.bugs@mingw.p.sourceforge.net",
    "full_slug" : "20130625120736:3193/20130625121849:08d1",
    "version" : 3,
    "flags" : 0,
    "timestamp" : ISODate("2013-06-25T12:18:49.711Z"),
    "author_id" : ObjectId("4d0620ec0594ca7bc3000566")
}

I see last_edit_date & mod_date are set. last_edit_by_id is keith, so that all matches what we see on the webpage.

The web log corresponding to that edit date is:

[25/Jun/2013:13:14:12 +0000] "POST /p/mingw/bugs/_discuss/thread/5b408c28/3193/08d1/reply HTTP/1.1" 302 267 "https://sourceforge.net/p/mingw/bugs/1995/"

That has /reply in it, which indicates the reply form was used (not edit form).

I don't have any suggestions for how to reliably duplicate it, unfortunately.

Originally by: andersbj

I typically see the problem if I preview a comment and then try to
post it from the preview. Sometimes just previewing it will discard my comment.

Closed #380.

Unfortunately, we're not able to fix this. Couple of developers tried to duplicate it, but it works well on local and sandbox setups. Code also looks okay. I'm thinking, maybe it's some problem with a production setup? Maybe someone from your team would be able to figure that out?

During testing we found some other bug, though. It goes like this:

1. Add a comment and couple of replies to it.
2. Delete the parent comment.
3. Try to reply to one of the former children of the deleted comment. You'll be redirected to url like /p/t380/tickets/_discuss/thread/f45821e2/ and your reply wouldn't show up.

Keith, Anders, or anyone else see this in the past few months? I used to see it myself probably once a week, but I haven't seen it for quite a while. I'm thinking it was fixed along the way with some other fixes.

Originally by: keithmarshall

It's definitely not fixed. The frequency seems to have reduced -- an entirely subjective and unmeasured perception -- but I have seen at least one incidence, perhaps two, within the last couple of weeks.

For a limited time we have lowered the rate on targeted website traffic. We have visitors from virtually every country on Earth. Each visitor is targeted by both country and keywords that you submit when you start your free trial period. If you need more visitors or product sales try our service free for seven days and we will send you 500 free visitors during the trial. There are no contracts and if you cancel during the trial period you will not be charged anything! Start your trial today: http://duckshop.co/1f1p

Unsubscribe here: http://stpicks.com/2ruse

I can duplicate this, it happens when the form has been open > 24hrs (the timeout for antispam logic) before submitting it.

Igor, I replicated this by changing allura/lib/utils.py:AntiSpam.validate_request so that it always raises a ValueError. E.g by lowering the 24hr to 1 second.

We should first, make it so the parent post doesn't get marked as edited - that's clearly a bug. Second, if there's an easy, generic way to preserve the content and re-populate the form that'd be good. I suspect that will be challenging though since this logic runs for all form submissions of any type. We may need to brainstorm other options if folks legitimately keep forms open that long very frequently.

• status: in-progress --> code-review

Closed #491. je/42cc_6381

The problem was that error_handler in reply controller passed POST requests to index, which handles post edits. We've fixed that.

Regarding re-populating the form. Seems like there's no easy way. We can retrieve form's content in our new error_handler and, say, pass it to redirect call and then re-populate with js, but it seems like there is no way to find out what form should be re-populated, since comment page often contains many forms (reply for each comment + general reply).

• status: code-review --> closed
• QA: Dave Brondsema

If a message doesn't pass the anti-spambot filter (e.g. page was open > 24hr), then the message will still be lost, but going forward it'll no longer mark the parent as edited.

As stated earlier, we don't have any good options to preserve content if it gets lost. (Personally I use http://getlazarus.com/ for a general solution - works well in Chrome, latest versions seem to not work in Firefox)