---
url: "https://vueda.dev/v3/reference/api/py/vueda.core.checks.md"
title: "core.checks"
---

# core.checks

## Overview

System checks validating VUEDA serializer configuration, model feature policy, and cache setup.

## `check_exclude_fields_serializer_usage` {#check_exclude_fields_serializer_usage}

Report ``ExcludeFieldsSerializerMixin`` serializers used as a nested field or an ``expandable_fields``
entry (``vueda_core.E007``, ``E008``), or as the ``serializer_class`` of a routed DRF view that is not
a ViewSet (``vueda_core.E021``).

``ExcludeFieldsSerializerMixin.get_extra_kwargs()`` picks its exclusions from the action of the view in
the serializer's context. A nested serializer shares its root serializer's context, so a nested copy of
the mixin would apply its exclusions for the parent view's action. That behavior is not supported, so
these uses are rejected. Only a ViewSet has an action, so the mixin raises ``ImproperlyConfigured``
whenever any other DRF view builds its fields. A serializer registered with ``register_serializer()`` is
not reported for having no ViewSet of its own. Without a view in context, the mixin excludes no fields.

### Signature {#check_exclude_fields_serializer_usage-signature}

`check_exclude_fields_serializer_usage(app_configs, kwargs)`

#### Parameters {#check_exclude_fields_serializer_usage-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| <span id="check_exclude_fields_serializer_usage-param-app_configs">app_configs</span> |  | yes |  |  |
| <span id="check_exclude_fields_serializer_usage-param-kwargs">kwargs</span> |  | no |  |  |

### Source {#check_exclude_fields_serializer_usage-source}

`server/vueda/core/checks.py:305`

## `check_expandable_fields_configuration` {#check_expandable_fields_configuration}

Validate every ``Meta.expandable_fields`` entry in the discovered serializer graph.

Each entry must have a valid shape and resolve to a serializer or field class. Its name must not be
``related`` or ``calculated``, because the VUEDA client reads a path that starts with either name from the
row's related or calculated object.

### Signature {#check_expandable_fields_configuration-signature}

`check_expandable_fields_configuration(app_configs, kwargs)`

#### Parameters {#check_expandable_fields_configuration-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| <span id="check_expandable_fields_configuration-param-app_configs">app_configs</span> |  | yes |  |  |
| <span id="check_expandable_fields_configuration-param-kwargs">kwargs</span> |  | no |  |  |

### Source {#check_expandable_fields_configuration-source}

`server/vueda/core/checks.py:287`

## `check_model_feature_declaration` {#check_model_feature_declaration}

Validate one model's ``class Vueda`` declaration and its resolved values.

### Signature {#check_model_feature_declaration-signature}

`check_model_feature_declaration(model)`

#### Parameters {#check_model_feature_declaration-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| <span id="check_model_feature_declaration-param-model">model</span> |  | yes |  |  |

### Source {#check_model_feature_declaration-source}

`server/vueda/core/checks.py:396`

## `check_model_feature_policy` {#check_model_feature_policy}

Report every fault in the ``class Vueda`` feature policy of the installed models.

Resolution itself never raises, so an unknown section, an unknown option, an invalid value, a
section whose feature app is absent, or a declaration on a proxy surfaces here rather than as an
import error while Django loads models.

### Signature {#check_model_feature_policy-signature}

`check_model_feature_policy(app_configs, kwargs)`

#### Parameters {#check_model_feature_policy-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| <span id="check_model_feature_policy-param-app_configs">app_configs</span> |  | yes |  |  |
| <span id="check_model_feature_policy-param-kwargs">kwargs</span> |  | no |  |  |

### Source {#check_model_feature_policy-source}

`server/vueda/core/checks.py:421`

## `check_permission_names_mapping` {#check_permission_names_mapping}

Report a ``PERMISSION_NAMES_MAPPING`` whose codenames ``ObjectPermissions`` does not check.

The mapping names the codenames Django writes when it creates permission rows. The
``ObjectPermissions`` codenames follow it in two cases only: the default mapping, and the
full mapping to Django's own names, which ``vueda.core.patch_django`` rewrites
``ObjectPermissions.perms_map`` for at import. Any other mapping creates rows that the
viewsets never check, so a grant of the renamed permission has no effect. A mapping to
Django's names that leaves out ``list`` also splits a list between two codenames: the
viewset checks ``view_``, and row-level list filtering checks ``list_``.

### Signature {#check_permission_names_mapping-signature}

`check_permission_names_mapping(app_configs, kwargs)`

#### Parameters {#check_permission_names_mapping-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| <span id="check_permission_names_mapping-param-app_configs">app_configs</span> |  | yes |  |  |
| <span id="check_permission_names_mapping-param-kwargs">kwargs</span> |  | no |  |  |

### Source {#check_permission_names_mapping-source}

`server/vueda/core/checks.py:492`

## `check_session_cache_is_shared` {#check_session_cache_is_shared}

Report sessions stored in a cache that worker processes cannot share.

``get_defaults`` requires ``CACHE_URL``, so the backend is a deliberate choice rather than a
silent default. ``locmem://`` and ``dummy://`` still satisfy that key. Behind more than one
worker process, a session written by one worker is missing from the next request another
serves, and the user loses the session at an unpredictable point.

Only ``django.contrib.sessions.backends.cache`` is reported. ``cached_db`` writes through to
the database, so a per-process cache costs it reads rather than sessions.

This is a deploy check, and it returns early while ``DEBUG`` is on, because a single-process
development server shares its cache with itself.

### Signature {#check_session_cache_is_shared-signature}

`check_session_cache_is_shared(app_configs, kwargs)`

#### Parameters {#check_session_cache_is_shared-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| <span id="check_session_cache_is_shared-param-app_configs">app_configs</span> |  | yes |  |  |
| <span id="check_session_cache_is_shared-param-kwargs">kwargs</span> |  | no |  |  |

### Source {#check_session_cache_is_shared-source}

`server/vueda/core/checks.py:448`

## Source

`server/vueda/core/checks.py`