pcas enum changes broken when there are subscribed clients
There are a couple of issues around changing enums in the pcas (relevant for REQUEST_ENUM):
As long as there are no subscribed clients, the current pcaspy version has no problem changing the enum. However, if there is a subscription and the enum becomes shorter, the length of the enum record in the pcas does not change and the extra fields retain their original strings. For example, here is the original channel:
$ caget -d31 T1:GRD-TEST3_REQUEST_ENUM
T1:GRD-TEST3_REQUEST_ENUM
Native data type: DBF_ENUM
Request type: DBR_CTRL_ENUM
Element count: 1
Value: NONE
Status: NO_ALARM
Severity: NO_ALARM
Enums: ( 5)
[ 0] A
[ 1] B
[ 2] C
[ 3] INIT
[ 4] NONE
If we remove an element with no subscriptions we get this:
$ caget -d31 T1:GRD-TEST3_REQUEST_ENUM
T1:GRD-TEST3_REQUEST_ENUM
Native data type: DBF_ENUM
Request type: DBR_CTRL_ENUM
Element count: 1
Value: NONE
Status: NO_ALARM
Severity: NO_ALARM
Enums: ( 4)
[ 0] A
[ 1] B
[ 2] INIT
[ 3] NONE
However, if there is at least one subscribed client to the REQUEST_ENUM channel we see this:
$ caget -d31 T1:GRD-TEST3_REQUEST_ENUM
T1:GRD-TEST3_REQUEST_ENUM
Native data type: DBF_ENUM
Request type: DBR_CTRL_ENUM
Element count: 1
Value: NONE
Status: NO_ALARM
Severity: NO_ALARM
Enums: ( 5)
[ 0] A
[ 1] B
[ 2] INIT
[ 3] NONE
[ 4] NONE
Note the length stays the same, and element 4 is as it was originally. Once all subscribed clients disconnect, the channel recovers:
$ caget -d31 T1:GRD-TEST3_REQUEST_ENUM
T1:GRD-TEST3_REQUEST_ENUM
Native data type: DBF_ENUM
Request type: DBR_CTRL_ENUM
Element count: 1
Value: NONE
Status: NO_ALARM
Severity: NO_ALARM
Enums: ( 4)
[ 0] A
[ 1] B
[ 2] INIT
[ 3] NONE
This obviously affects all other clients, so is quite problematic.