Re: <bug>: neuen Pat. aufgerufen

[Karsten Hilbert]

Hello Karsten,

> user comment  : neuen Pat. aufgerufen
>
> client version: 1.8.5
>
> system account: gnumed
> staff member  : Karsten Heinrich (KaHe = kahe)
> sender email  : <E-Mail eintragen für Rückmeldungen zum Fehler>
>
>  # enable Launchpad bug tracking
>  affects gnumed
>  tag automatic-report
>  importance medium
>
> Exception:
>
>  type: <class 'Gnumed.pycommon.gmExceptions.ConstructorError'>
>  value: [cEncounter:50973]: error loading instance
>
> Traceback:
>
>   File "/usr/lib/python3/dist-packages/wx/core.py", line 3259, in <lambda>
>     lambda event: event.callable(*event.args, **event.kw) )
>   File "/usr/share/gnumed/Gnumed/business/gmClinicalRecord.py", line 261, in 
> db_modification_callback
>     curr_enc_in_db = gmEMRStructItems.cEncounter(aPK_obj = 
> self.current_encounter['pk_encounter'])
>   File "/usr/share/gnumed/Gnumed/pycommon/gmBusinessDBObject.py", line 335, 
> in __init__
>     self.__init_from_pk(aPK_obj = aPK_obj, link_obj = link_obj)
>   File "/usr/share/gnumed/Gnumed/pycommon/gmBusinessDBObject.py", line 363, 
> in __init_from_pk
>     raise gmExceptions.ConstructorError("[%s:%s]: error loading instance" % 
> (self.__class__.__name__, self.pk_obj))

The problem you have seen is very interesting (and hopefully
fixed now).

While your client was having open a patient with a specific
encounter being active another client seems to have opened
that same patient and have somehow effected a deletion of
that active encounter. Your client receives a database change
notification:

>   File "/usr/share/gnumed/Gnumed/business/gmClinicalRecord.py", line 261, in 
> db_modification_callback

and tries to load the encounter to check for what changes
have been applied remotely, if any:

>     curr_enc_in_db = gmEMRStructItems.cEncounter(aPK_obj = 
> self.current_encounter['pk_encounter'])

That fails, however:

>     raise gmExceptions.ConstructorError("[%s:%s]: error loading instance" % 
> (self.__class__.__name__, self.pk_obj))

because the change was a DELETE:

> 2021-06-02 16:54:03  DEBUG     gm.logging    [3082571456 MainThread]  
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #213):        
>          kwds = {'signal': 'gm_table_mod', 'sender': None, 
> 'originated_in_database': True, 'listener_pid': 12389, 'sending_backend_pid': 
> 21921, 'pk_identity': 12812, 'operation': 'DELETE', 'table': 
> 'clin.encounter', 'pk_column_name': 'pk', 'pk_of_row': 50973, 
> 'message_index': 2491, 'notification_index': 1246}

IOW, the encounter is now *gone* and cannot be reloaded.

There's a fairly complex maze of things to be considered :-)

1) GNUmed did not, at all, take into account that
possibility, and reacted disgracefully, as you
discovered.

        It now does, by newly attaching to (a) current encounter.

2) It was not thought possible for the currently active
encounter to disappear because GNUmed uses a lock on it.

        However, the lock, while being held *inside* the
        database, is only by co-operation (an advisory lock) and
        is not being held *on* the encounter directly.

There's two ways the lock can be overcome that I can think of:

1) The encounter in question

        is older than either 3 days or the defined minimum
        encounter age (whichever is longer) -- IOW, the client
        holding the encounter as active has been open for three
        days on that patient, and

        is "empty", and

        is one of more than 2 encounters for that patient

In this case, when another client comes along and opens the
patient, it will instruct the database to delete "old empty
encounters" on its behalf, WHICH DOES NOT CHECK THE LOCK.

It now does.

2) There is a (client) coding error regarding the lock.

        I can't find one, however.

So, this *should* not happen anymore ...

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B