Welcome to the forum @Zeyu !
In v4.7.0, we implemented some guards to no longer allow Live session-related jobs to be controlled by user actions, because we found that users modifying jobs directly (killing, clearing, cloning, etc) could often put the Live session into an inconsistent database state and cause issues with processing. In fact it was never an intended behaviour that Live jobs should be directly interactable; for v4.7.0 we considered it to be a bug. Instead, jobs spawned by a Live session are meant to be controlled indirectly, for example by pausing the Live session.
Could you explain more about your workflow that involved using the Kill Job action on Live Worker jobs in the past? It would help us to know what the goal was, and perhaps there is a way that can be built in to Live session management.
Thank you!