[Core feature] Add new config to disable fallback to container task handler

[MortalHappiness]

Motivation: Why do you think this is important?

If a task does not have a registered plugin handler, it will fallback to the container task handler. We usually do not want this behavior and expect the task without the corresponding task handlers to fail directly.

Goal: What should the final outcome look like, ideally?

Add a new config to allow users to prevent the default fallback task handler.

Describe alternatives you've considered

N/A

Propose: Link/Inline OR Additional context

No response

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[MortalHappiness]

#take

[dosubot]

It seems like you've got this under control, if you want help or have specific questions, let me know what I can do for you!

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[eapolinario]

@MortalHappiness , before we consider this more seriously, can you talk about your use case a bit more?

[MortalHappiness]

@eapolinario For example, if we create a Ray task and forget to install the Ray operator, it will fallback to use the container handler to run the task, which seems to be fine and the result is correct. However, no matter how many replicas you specified in your task, there will be only one container because the task is run as a container task instead of a Ray task.