c2c-oerpscenario team mailing list archive

[xrg <xrg@xxxxxxxxx>]

Public bug reported:

A /broken/ model (report.membership) at the server happened to return
duplicate ids of records (using a badly migrated dataset, too). This
propagated to the Gtk client, which inserted the ids at duplicate
positions of the list view. When iterating over them, the client was
trapped into an OOM, which is critical and DoSes the host desktop.

The server should never have done that, agreed. But, the network principle
says "send clean, accept garbage", so we'd better not die if such data
ever come again.
Gently logging the case was the way to go. If we raise an exception (tried
that), the Gtk framework will come back asking for the list item again,
which ends up in an ugly full-load (but not lethal) of the client (and a
few more calls to the server).

** Affects: openobject-client
     Importance: Undecided
         Status: New


** Tags: list

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/728275

Title:
  view/list: Fix handling of duplicate IDs from search()

Status in OpenERP GTK Client:
  New

Bug description:
  A /broken/ model (report.membership) at the server happened to return
  duplicate ids of records (using a badly migrated dataset, too). This
  propagated to the Gtk client, which inserted the ids at duplicate
  positions of the list view. When iterating over them, the client was
  trapped into an OOM, which is critical and DoSes the host desktop.

  The server should never have done that, agreed. But, the network principle
  says "send clean, accept garbage", so we'd better not die if such data
  ever come again.
  Gently logging the case was the way to go. If we raise an exception (tried
  that), the Gtk framework will come back asking for the list item again,
  which ends up in an ugly full-load (but not lethal) of the client (and a
  few more calls to the server).