Creates lots of duplicates

[Corey Burger]

Malone seems to create duplicates

Malone seems to create duplicates. There are two possible reasons for this:

1. Malone dumps you out to main page after filing, which leads you to believe that it didn't take the bug (bug already filed for this)

2. It is actually creating duplicates.

[Christian Reis (kiko)]

Hey Corey, thanks for the report. Can you elaborate on the problem? What are the "lots of duplicates" you are seeing? I've seen a few -- 788 and 789 sprint to mind.

It may be that one issue is that clicking on (( Add )) multiple times spawns multiple bugs. Do you confirm?

[Christian Reis (kiko)]

Spoke to Corey on #launchpad about this for a bit. The duplicates are always sequential and always have identical content, so it's likely to be double-posted bugs (i.e. clicking on Add twice).

Two solutions:

  - Add a [random?] ID to the bug page and store that in the database; ensure that ID is unique when inserting and error out to the user if it's not. This will require some thinking as to where we store this ID, how we avoid collisions, etc.
  - Compare the contents of the posted bug -- title and comment -- and ensure they are different from title and comment of the bug immediately posted before this one. This one invites race conditions, so we could use a range, but is also a bit tricky.

I know Bugzilla has the same issue. There are a couple of bugs covering this:
  - https://bugzilla.mozilla.org/show_bug.cgi?id=46843
  - https://bugzilla.mozilla.org/show_bug.cgi?id=42946
  - https://bugzilla.mozilla.org/show_bug.cgi?id=22353 (more ambitious, less practical)

[Steve Alexander (stevea)]

As an initial easy fix, we can hook some javascript up to the button to disable it after it has been clicked once.

It is tricky to handle this issue in the database, because there's an inherent race. The transactions will almost always overlap.

There are two approaches I can suggest to handle this.

1. Have a database that is not tied into the same transactions as the main database, so we don't get that same race. A special ZODB would serve for this. We generate a unique form-submission id when we render a form, when we receive the submission, store this in the special database, and on receiving a form submission, check that we don't have that id in the database already. We don't need to keep the data for very long, so a temporary data store is okay. It has to run outside of our normal transactions so that we can use it to detect these potentially overlapping transactions.

2. Make the object publisher sensitive to when the client has dropped the connection. When you click the same button twice, before you've received a response, your browser will usually drop the first connection and make a second connection. I don't know if we can get this information once the request has been proxied through apache, though.

[Matthew Paul Thomas (mpt)]

Deactivating the button after first click was my first thought too. But that would be really annoying if Launchpad really *had* timed out without registering your report (oh, someone's downloading from Rosetta!), and you were sitting there with a carefully filled out page and no way of submitting it.

[Christian Reis (kiko)]

Steve'a approach #1 using the ZODB is grand, and he's totally right, the information doesn't need to hang around for long. Sounds like a plan.

[Brad Bollenbach (bradb)]

A simple solution here might be to ensure that bug titles are constrained to be unique.

I'm going to mark this as low priority for now, until we get more of the moving parts working.

[Diogo Matsubara (matsubara)]

Does this still happen?

[Joey Stanford (joey)]

Corey, does this still happen?

[Corey Burger (corey.burger)]

I haven't seen it recently, nor have I seen the flood of dulicate bug filings that happened around the time this bug was entered. I would close unless somebody else can confirm.