HumanSignal/label-studio · warning · ValidationError

{e.detail[0]} [assume: item["data"] = task root with values]

Error message

{e.detail[0]} [assume: item["data"] = task root with values]

What it means

The dict_is_root=False counterpart of [224]: check_data_and_root re-raises the inner check_data message with the appended hint " [assume: item[\"data\"] = task root with values]". This is the default path when an item HAS a 'data' key (validate -> raise_if_wrong_class('data',(dict,list)) -> check_data_and_root(project, task['data'])), meaning the value of item['data'] failed validation. The hint tells the user the payload inside item['data'] was validated as the task root.

Source

Thrown at label_studio/tasks/validation.py:113

        return data

    @staticmethod
    def check_data_and_root(project, data, dict_is_root=False):
        """Check data consistent and data is dict with task or dict['task'] is task

        :param project:
        :param data:
        :param dict_is_root:
        :return:
        """
        try:
            TaskValidator.check_data(project, data)
        except ValidationError as e:
            if dict_is_root:
                raise ValidationError(e.detail[0] + ' [assume: item as is = task root with values] ')
            else:
                raise ValidationError(e.detail[0] + ' [assume: item["data"] = task root with values]')

    @staticmethod
    def check_allowed(task):
        # task is required
        if 'data' not in task:
            return False

        # everything is ok
        return True

    @staticmethod
    def raise_if_wrong_class(task, key, class_def):
        if key in task and not isinstance(task[key], class_def):
            if isinstance(class_def, tuple):
                class_def = ' or '.join([c.__name__ for c in class_def])
            else:
                class_def = class_def.__name__
            raise ValidationError('Task[{key}] must be {class_def}'.format(key=key, class_def=class_def))

View on GitHub (pinned to 0b49e9b539)

Solutions

1. Fix the issue described in the message prefix (missing key / wrong type / None data) inside item['data']
2. Verify the keys in item['data'] exactly match the $variables in the labeling config
3. Run a local pre-check: for each config key, assert key in payload and isinstance matches _DATA_TYPES
4. If 'data' was meant to be the root itself, restructure to the bare-dict form (dict_is_root path) deliberately

Example fix

// before
{'data': {'sentence': 'hello'}}  # config: <Text value="$text"/>
// after
{'data': {'text': 'hello'}}

def validate_wrapped(task, data_types):
    data = task.get('data')
    if not isinstance(data, dict):
        raise ValueError('task["data"] must be a dict')
    for key, tag in data_types.items():
        key = key.split('[')[0]
        if '.' not in key and key not in data:
            raise ValueError(f'data missing {key}')

def has_valid_data(task):
    return isinstance(task, dict) and isinstance(task.get('data'), dict)

try:
    import_tasks(tasks)
except ValidationError as e:
    msg = str(e.detail[0])
    if 'item["data"] = task root' in msg:
        fix_inner_data(msg, tasks)  # parse prefix and repair the inner dicts

When it happens

Trigger: Importing {'data': {...}} where the inner dict is None, missing a required config key, or has a value of the wrong type — e.g. {'data': {'sentence': 'x'}} with config referencing $text, or {'data': None}.

Common situations: API imports via /api/tasks or project import with wrapped payloads; SDK import_tasks calls; post-edit saves through TaskSerializer.validate where instance.data parsing succeeded but config validation failed.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

• Task is empty (None)
• {e.detail[0]} [assume: item as is = task root with values]
• Maximum task number is {settings.TASKS_MAX_NUMBER}, current
• Maximum total size of all files is {settings.TASKS_MAX_FILE_
• {ext} extension is not supported

AI-assisted analysis of HumanSignal/label-studio@0b49e9b539 (2026-08-29). Data as JSON: /api/errors/8b418085dfae54ce. Report an issue: GitHub.