microsoft/qlib · error · NotImplementedError

This type of input is not supported

Error message

This type of input is not supported

What it means

Same inst_processor guard as cache.py:706/762, on the ClientDatasetProvider path (qlib/data/cache.py:1147): when inst_processors is non-empty and disk_cache != 0, the provider cannot use the shared dataset cache (its contents are processor-independent), so it raises ValueError directing you to disk_cache=0 or dataset_cache=None.

Source

Thrown at qlib/backtest/decision.py:129

        - `+1` indicates buying
        - `-1` value indicates selling
        """
        return self.direction * 2 - 1

    @staticmethod
    def parse_dir(direction: Union[str, int, np.integer, OrderDir, np.ndarray]) -> Union[OrderDir, np.ndarray]:
        if isinstance(direction, OrderDir):
            return direction
        elif isinstance(direction, (int, float, np.integer, np.floating)):
            return Order.BUY if direction > 0 else Order.SELL
        elif isinstance(direction, str):
            dl = direction.lower().strip()
            if dl == "sell":
                return OrderDir.SELL
            elif dl == "buy":
                return OrderDir.BUY
            else:
                raise NotImplementedError(f"This type of input is not supported")
        elif isinstance(direction, np.ndarray):
            direction_array = direction.copy()
            direction_array[direction_array > 0] = Order.BUY
            direction_array[direction_array <= 0] = Order.SELL
            return direction_array
        else:
            raise NotImplementedError(f"This type of input is not supported")

    @property
    def key_by_day(self) -> tuple:
        """A hashable & unique key to identify this order, under the granularity in day."""
        return self.stock_id, self.date, self.direction

    @property
    def key(self) -> tuple:
        """A hashable & unique key to identify this order."""
        return self.stock_id, self.start_time, self.end_time, self.direction

View on GitHub (pinned to 79633dd950)

Solutions

  1. Use D.features(..., disk_cache=0, inst_processors=[...]) on the client so processors apply post-load
  2. Initialize without a dataset cache: qlib.init(dataset_cache=None)
  3. Relocate instrument processing into the dataset/processor layer (DataHandlerLP processors) so raw cached data remains shareable

Example fix

# before
D.features(insts, fields, start, end, inst_processors=[p])  # client + dataset cache -> ValueError

# after
D.features(insts, fields, start, end, disk_cache=0, inst_processors=[p])
Defensive patterns

Strategy: validation

Validate before calling

# client-side rule: processors force cache bypass
df = D.features(insts, fields, start, end,
                disk_cache=0 if inst_processors else 1,
                inst_processors=inst_processors)

Type guard

def bypass_dataset_cache(inst_processors) -> bool:
    return bool(inst_processors)

Try / catch

try:
    df = client_D.features(insts, fields, start, end, inst_processors=procs)
except ValueError as e:
    if "does not support inst_processor" in str(e):
        df = client_D.features(insts, fields, start, end, disk_cache=0, inst_processors=procs)
    else:
        raise

Prevention

When it happens

Trigger: Client/server mode: client requests D.features(..., inst_processors=[...]) with the default disk_cache while a dataset cache is configured server-side; the provider falls into the cache-URI branch (self._uri + provider.dataset with return_uri) and hits the guard.

Common situations: Deployments adding per-instrument normalization processors to an existing cached pipeline; mixing ClientDatasetProvider with instrument processors without adjusting disk_cache.

Related errors


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