Currently it is possible to put the whole PU in quiesce mode. Sometimes the user wants to keep working with the PU and put only one PU instance in quiesce.
This feature will be used for the following user story:
We have run into an issue where lease expiration events are not been received due to relocation of a processing unit instance. The problem is a logical one. I've attached a code sample to illustrate this.
To reproduce the issue perform the following actions
deploy the contained processing unit (1 primary/1 backup)
start the ExternalActionTrigger main function as an external process
This will continuously write objects with a sequence counter and a lease expiration time to the space
relocate the primary partition to another GSC using the drag & drop feature of the GS management center
Before the relocation, the console output shows the expiration events in perfect sequence without any number gaps. As the relocation is triggered lease processing is stopped until the backup takes over. The problematic part is, that this creates a gap in the sequence numbering, indicating a loss of an expiration event.
This happens because there is a small time window where destroy() of the processing units service code has been called, but the space is still operating in a normal fashion where instances will expire. The provided example artificially extends this time window. It is smaller in "real" application, nonetheless this window is still there.
During service-destroy we perform a destroy of the notification container (as recommended in the docs). If a lease expires in the primary partition after we have destroyed the notification container, the service code will no longer be informed about this event, which in turn results in inconsistent state.
I put this feature in Minor priority as the customer has workaround.