mainSavannah Administration - Support: sr #111059, stop discarding infromation in...

 
 

sr #111059: stop discarding infromation in "Duplicate posts"

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Mon 06 May 2024 04:16:26 AM UTC
   
 
Category:  Savannah trackers - bugs, tasks, etc. Priority:  5 - Normal
Severity:  3 - Normal Status:  In Progress
Privacy:  Public Assigned to:  ineiev
Operating System:  None Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 06 May 2024 03:48:24 PM UTC, comment #3: 

comment #2:

> original submission:
> > what I want to see is a dump of the field changes that were submitted, and above all the text of the comment that couldn't be posted, because that often takes a lot of time and thought to compose.
>
> Thank you, done.


Thank you!  Unlike Branden's experience, my browser tends not to cache this data, so being able to recover it is immensely helpful.

> comment #1:
> > ...it does nothing to prevent collisions...
>
> No, it doesn't.  The server could add the previous state to the form and then check against it, but that would be more than a dozen or two lines of Savane code.


And is a separate issue, so should have its own ticket if something is to be done with it.  I'd like to see it, but it's low priority for me.

Dave <barx>
Mon 06 May 2024 11:47:14 AM UTC, comment #2: 

[reordered]

original submission:
...

> what I want to see is a dump of the field changes that were submitted, and above all the text of the comment that couldn't be posted, because that often takes a lot of time and thought to compose.


Thank you, done.

...

> I believe I understand the necessity of not performing a ticket update against stale data.


This feature isn't really intended for dealing with 'stale' data, it's about posting the same message multiple times, and more important, it is used to block cross-site scripting.

> ...So possibly "Duplicate post" is being thrown for spurious or excessively aggressive reasons, like the age of some cookie, or because some server got rebooted.


It may, but at this point, I have no sufficient data to tell.  The feature doesn't depend on cookies in the strict sense or on rebooting the server.  This is how it works.

When a user visits a page containing a form, a form_id token is saved in Savane database and inserted on the page; when the form is submitted, the request is only honored when the token is present both in the request and in the database (e.g. a malicious page from a third party website can't embed it), and at the same time the token is removed from the database.  Then, a cron job removes the tokens more than a day old; that period could be increased, but we should clear them at some point.

I'm not sure how this mechanism can be improved or replaced.

comment #1:

> ...it does nothing to prevent collisions...


No, it doesn't.  The server could add the previous state to the form and then check against it, but that would be more than a dozen or two lines of Savane code.

Ineiev <ineiev>
Site Administrator
Mon 06 May 2024 04:23:50 AM UTC, comment #1: 

That's happened to me several times too, usually when I try to comment on a bug that's been sitting in a browser tab for a while, even if there's been no activity in the bug since I opened that tab.  There does seem to be some time limit to a bug page.

I don't know the purpose of this limit, since it does nothing to prevent collisions: on a freshly opened tab, you can write a comment to a bug and successfully submit it, and if someone updated fields in the bug while you were typing your comment, your update will undo those changes.

Dave <barx>
Mon 06 May 2024 04:16:26 AM UTC, original submission:  

A few minutes ago I submitted a lengthy comment to a Savannah ticket, bug #64155.

Upon submitting it, Savannah rejected it.

"Duplicate Post: this form was already submitted."

So I clicked back in my browser, because at least until recently, my browser cached the values of the form controls.

Nope.  Not this time.

"Document Expired".

My work?  Thrown away.

I believe I understand the necessity of not performing a ticket update against stale data.  (However, I observe that this usually does not seem to be the case with groff tickets I work with.  Indeed, if I check the History blind of bug #64155, I see that the ticket hasn't been updated in nearly 24 hours.  So possibly "Duplicate post" is being thrown for spurious or excessively aggressive reasons, like the age of some cookie, or because some server got rebooted.)

Nevertheless it's pretty dispiriting to throw away a user's attempted changes to a ticket, with a nearly blank screen telling them "they" screwed up somehow.  But they didn't.  There's no way to tell in advance if you're going to be submitting a "duplicate" form.

Maybe it should be called a "stale form".

But more than that what I want to see is a dump of the field changes that were submitted, and above all the text of the comment that couldn't be posted, because that often takes a lot of time and thought to compose.

Thank you for your consideration.

G. Branden Robinson <gbranden>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-06 ineiev StatusNone In Progress
        Assigned toNone ineiev

    Back to the top

    Powered by Savane 3.13-4e86.
    Corresponding source code