CMFActivity.Activity.SQLBase: Tolerate group_id set without a grouping_method_id.
While it does not make sense, it is possible to spawn activities with a group_id set but without a grouping_metohd_id. This is for example easy to trigger using recurseCallMethod from ERP5Type.Core.Folder: the _recurseCallMethod activity spawned nullifies grouping_method_id but does not (currently) clean group_id, leading to inconsistency between how "non-groupped" conditions are evaluated in getProcessableMessageList and dequeueMessage. The consequence is zombie activities: they never fail, do not prevent other activities from being executed, but and are permanently run on the node which reserved more than one because: - all but one activity is in MESSAGE_NOT_EXECUTED state, forcing an abort - finalizeMessageExecution does not understand that MESSAGE_NOT_EXECUTED activities may not have failed, and itself fail while trying to detect the failure type (ConflictError vs. others), failing to free & postpone the activity, in turn failing to bring it to eventually permanent failure state. Make those conditions consistent, and use tuple-unpacking to detect any future inconsistency much earlier, simplifying debugging.
Showing
Please register or sign in to comment