#6381 Allura tickets system intermittently discards replies to comments [ss4454]

Chris Tsai

Ref: [allura:tickets:#4454]


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.

This is happening way too often; it is becoming increasingly frustrating.


Can you provide a time frame for when this has been occurring (we've been working through some site issues the past few days which I could see as related) and some specific examples that we can check the logs for?

Also, as a personal recommendation, I've been using the Lazarus browser plugin (for FF and Chrome), and helped me recover lost text on many occasions.


I've noticed it intermittently, over several months; pretty much, ever since MinGW migrated to the Allura platform. Most recent occurrence was today, (just a short while before I raised this issue itself), when I attempted to add the side issue references on https://sourceforge.net/p/mingw/bugs/1989/

I experienced a similar issue yesterday, on https://sourceforge.net/p/mingw/bugs/1973/ (I think); tracking down any earlier occurrences may be too difficult to contemplate, but there have been several.

Thanks for the Lazarus pointer; I'll certainly look into it. However, I've simply gotten into the habit of using Ctrl-A Ctrl-C in the input pane, just prior to selecting "post reply".

One further point, which may or may not be related: sometimes, when a reply is successfully posted, it becomes divorced from its parent, and presented as an apparent top level discussion item, (usually with an intervening "page break").

So we don't need to do a lot of timestamp comparing to figure out which reply specifically, it looks like it's this one: https://sourceforge.net/p/mingw/bugs/1989/#3e85/cd7b/d222/aba9/76e9


Tickets: #6381


  • Chris Tsai - 2013-06-20
    • Description has changed:


    --- old
    +++ new
    @@ -1,3 +1,4 @@
    +Ref: [allura:tickets:#4454]
     >>>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.
  • Anonymous - 2013-06-20

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

  • Dave Brondsema

    Dave Brondsema - 2013-06-21
    • labels: support, p2 --> support, p2, 42cc
    • Milestone: limbo --> forge-backlog
  • Dave Brondsema

    Dave Brondsema - 2013-06-21

    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.

  • Anonymous - 2013-06-24

    Originally by: keithmarshall

    Another occurrence: posting a top level response to


    took me to


    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.

  • Anonymous - 2013-06-24

    Originally by: keithmarshall

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


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

  • Dave Brondsema

    Dave Brondsema - 2013-06-24

    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.

  • Anonymous - 2013-06-24

    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.

  • Anonymous - 2013-06-24

    Originally by: keithmarshall

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

  • Igor Bondarenko

    Igor Bondarenko - 2013-06-24
    • status: open --> in-progress
  • Igor Bondarenko

    Igor Bondarenko - 2013-06-24

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



    Tickets: #6381

  • Igor Bondarenko

    Igor Bondarenko - 2013-06-25

    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.

  • Anonymous - 2013-06-25

    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.

  • Dave Brondsema

    Dave Brondsema - 2013-06-25

    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:

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

  • Anonymous - 2013-09-17

    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.

  • Igor Bondarenko

    Igor Bondarenko - 2013-10-15

    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.
  • Dave Brondsema

    Dave Brondsema - 2013-11-06

    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.

  • Anonymous - 2013-11-07

    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.

  • Anonymous - 2013-11-07

    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


    Last edit: Anonymous 2018-09-18
  • Dave Brondsema

    Dave Brondsema - 2013-11-08

    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.

  • Igor Bondarenko

    Igor Bondarenko - 2013-12-02
    • status: in-progress --> code-review
  • Igor Bondarenko

    Igor Bondarenko - 2013-12-02

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

  • Dave Brondsema

    Dave Brondsema - 2013-12-10
    • status: code-review --> closed
    • QA: Dave Brondsema
  • Dave Brondsema

    Dave Brondsema - 2013-12-10

    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)


Log in to post a comment.