What causes "This type of input is not supported" in microsoft/qlib?

Pass the horizon argument when constructing the rolling task, e.g. horizon=1

microsoft/qlib · error · NotImplementedError

This type of input is not supported

Error message

This type of input is not supported

What it means

Rolling base class (qlib/contrib/rolling/base.py) rewrites a task's label horizon on every basic_task() call. It can only do that when the user supplies an explicit horizon; if self.horizon is None there is no way to derive it automatically (an acknowledged TODO), so NotImplementedError is raised.

Source

Thrown at qlib/contrib/rolling/base.py:161

        return task

    def basic_task(self, enable_handler_cache: Optional[bool] = True):
        """
        The basic task may not be the exactly same as the config from `conf_path` from __init__ due to
        - some parameters could be overriding by some parameters from __init__
        - user could implementing sublcass to change it for higher performance
        """
        task: dict = self._raw_conf()["task"]
        task = deepcopy(task)

        # modify dataset horizon
        # NOTE:
        # It assumpts that the label can be modifiled in the handler's kwargs
        # But is not always a valid. It is only valid in the predefined dataset `Alpha158` & `Alpha360`
        if self.horizon is None:
            # TODO:
            # - get horizon automatically from the expression!!!!
            raise NotImplementedError(f"This type of input is not supported")
        else:
            if enable_handler_cache and self.h_path is not None:
                self.logger.info("Fail to override the horizon due to data handler cache")
            else:
                self.logger.info("The prediction horizon is overrided")
                if isinstance(task["dataset"]["kwargs"]["handler"], dict):
                    task["dataset"]["kwargs"]["handler"]["kwargs"]["label"] = [
                        "Ref($close, -{}) / Ref($close, -1) - 1".format(self.horizon + 1)
                    ]
                else:
                    self.logger.warning("Try to automatically configure the lablel but failed.")

        if self.h_path is not None or enable_handler_cache:
            # if we already have provided data source or we want to create one
            task = self._replace_handler_with_cache(task)
        task = self._update_start_end_time(task)

        if self.task_ext_conf is not None:

View on GitHub (pinned to 79633dd950)

Solutions

Pass the horizon argument when constructing the rolling task, e.g. horizon=1
Set it in the rolling workflow config under the corresponding key so self.horizon is populated
If you subclass Rolling, you may override basic_task to supply horizon from your own label expression

Example fix

# before
roll = DDGDA(..., steps=40, horizon=None)

# after
roll = DDGDA(..., steps=40, horizon=1)

Defensive patterns

Strategy: validation

Validate before calling

assert horizon is not None and int(horizon) > 0, 'Rolling tasks require an explicit horizon (e.g. horizon=1)'
roll = DDGDA(..., horizon=horizon)

Prevention

Always set horizon in rolling-retraining configs; it cannot be auto-derived from the label expression yet
Validate rolling workflow YAMLs against the shipped examples before running

When it happens

Trigger: Constructing a Rolling task manager (e.g. DDGDA, Rolling) without the horizon argument and then calling basic_task() or a workflow step that calls it (run / _get_task_temp_related).

Common situations: Copying a benchmark workflow config for rolling retraining but omitting the horizon field; assuming horizon is inferred from the Alpha158/Alpha360 label expression automatically.

Related errors

AI-assisted analysis of microsoft/qlib@79633dd950 (2026-08-15). Data as JSON: /api/errors/6b9eeedd47a0b16e. Report an issue: GitHub.