GTM-8842 fixed this issue in GT.M V6.3-003 but the fix seems incorrect. The change was
done in op_set_zbreak() to return if we are inside a trigger. But by the time op_set_zbreak()
is invoked, the transfer table has already been changed by op_zstep.c in preparation for
the ZSTEP action. This undo happens much later when op_set_zbreak() is called after we
finish executing the trigger at which point, the current $ZSTEP action is executed too.
This is an unintended side effect which is considered incorrect. A ZSTEP action which was
ignored while inside a trigger should continue to be ignored after exiting the trigger too.
The fix is to remove the change done in op_set_zbreak() but move that check to op_zstep.c
so we do not do any transfer table change while inside a trigger and if TRIGGER_MOD restriction
is currently on. This change to op_zstep.c mirrors a change to op_zbreak.c done as part of
GTM-8842.
GTM-8842 fixed this issue in GT.M V6.3-003 but the fix seems incorrect. The change was done in op_set_zbreak() to return if we are inside a trigger. But by the time op_set_zbreak() is invoked, the transfer table has already been changed by op_zstep.c in preparation for the ZSTEP action. This undo happens much later when op_set_zbreak() is called after we finish executing the trigger at which point, the current $ZSTEP action is executed too. This is an unintended side effect which is considered incorrect. A ZSTEP action which was ignored while inside a trigger should continue to be ignored after exiting the trigger too.
The fix is to remove the change done in op_set_zbreak() but move that check to op_zstep.c so we do not do any transfer table change while inside a trigger and if TRIGGER_MOD restriction is currently on. This change to op_zstep.c mirrors a change to op_zbreak.c done as part of GTM-8842.