[Error] Class "SpecialCharsEnum" not found error

[beeritis]

Using apache:default tag v8.0.1(1029) Default .

We get this constant error every minute in the system log .

Doesn't seem to be breaking anything but could use fixing.

[beeritis]

Example error :

[Error] Class "SpecialCharsEnum" not found
at BaseModel->init (services.php:90)
at ServicesImpl->_create (services.php:59)
at ServicesImpl->get (services.php:27)
at Services::get (loader.php:65)
at Loader_core->_object (loader.php:80)
at Loader_core->_model (loader.php:92)
at Loader_core->model (settings.php:31)
at Settings_library->init (services.php:90)
at ServicesImpl->_create (services.php:59)
at ServicesImpl->get (services.php:27)
at Services::get (loader.php:65)
at Loader_core->_object (loader.php:126)
at Loader_core->library (task.php:25)
at TaskController->_init (tasks.php:18)
at Tasks_controller->_init (gizmo.php:128)
at require_once (index.php:114)
at require_once (task.php:81)

[nachoxcasas]

Same here. I'm doing a PoC of migration from 7.5 to 8 and I found same error.

[Mik4sa]

The same errors happens when running task.php (the background task). So this might break the background task?

[FaraSys]

Hi.
I have the same error when i try generate report

[Error] Class "SpecialCharsEnum" not found
at BaseModel->init (services.php:90)
at ServicesImpl->_create (services.php:59)
at ServicesImpl->get (services.php:27)
at Services::get (loader.php:65)
at Loader_core->_object (loader.php:80)
at Loader_core->_model (loader.php:92)
at Loader_core->model (settings.php:31)
at Settings_library->init (services.php:90)
at ServicesImpl->_create (services.php:59)
at ServicesImpl->get (services.php:27)
at Services::get (loader.php:65)
at Loader_core->_object (loader.php:126)
at Loader_core->library (task.php:25)
at TaskController->_init (tasks.php:18)
at Tasks_controller->_init (gizmo.php:128)
at require_once (index.php:114)
at require_once (task.php:81)

[jalvarez-raft]

is there a fix for this?

[beeritis]

This may have been fixed in a later release, however the developers don't seem to favour self hosted and prioritise cloud releases . I can't see it being fixed any time soon until a new image is released.

[Mik4sa]

Ignore my comment from above. So I found a workaround (for me).
See here: Com-In-GmbH-Co-KG-Consulting-Solutions@3f41015
Maybe you need to make some little modifications for you to work.
So the current task.php (root directory) has this part:

// Check for environment variables/options that can influence the
// runtime behavior of the task and set them as defines, if found.
$envs = array(
    'DEPLOY_INSTANCE_ID',
    'DEPLOY_HOSTNAME',
    'DEPLOY_INSTALLATION_URL',
    'DEPLOY_ATTACHMENT_PATH',
    'DEPLOY_BACKUP_PATH',
    'DEPLOY_CUSTOM_PATH',
    'DEPLOY_EXPORT_PATH',
    'DEPLOY_LOG_PATH',
    'LOG_OUTPUT_TYPE',
    'DEPLOY_REQUEST_HOSTED',
    'DEPLOY_REPORT_PATH',
    'DEPLOY_DEBUG',
    'DEPLOY_DEBUG_TASK',
    'DEPLOY_PROXY_HOST',
    'DEPLOY_PROXY_PORT',
    'DB_DRIVER',
    'DB_HOSTNAME',
    'DB_DATABASE',
    'DB_USERNAME',
    'DB_PASSWORD',
    'CASSANDRA_HOSTNAME',
    'CASSANDRA_PORT',
    'CASSANDRA_KEYSPACE',
    'CASSANDRA_USERNAME',
    'CASSANDRA_PASSWORD',
    'RABBITMQ_HOST',
    'RABBITMQ_PORT',
    'RABBITMQ_USER',
    'RABBITMQ_PASSWORD',
    'RABBITMQ_USE_SSL',
    'DEPLOY_TASK_REMOVE_ATTACHMENTS_INTERVAL',
    'DEPLOY_TASK_REMOVE_ATTACHMENTS_REMOVAL_TIME_INTERVAL',
    'DEPLOY_LICENSE_ENTERPRISE',
    'ATTACHMENT_SIZE',
    'DATABASE_SIZE',
    'STORAGE_HARD_LIMIT',
    'STORAGE_SOFT_LIMIT',
    'ENTERPRISE_STORAGE_HARD_LIMIT',
    'ENTERPRISE_STORAGE_SOFT_LIMIT',
    'DEPLOY_LICENSE_INSTANCE_ID',
    'DEPLOY_LICENSE_ACCOUNT',
    'DEPLOY_LICENSE_ACCOUNT_TYPE',
    'APPLICATION_CONFIG',
    'DEPLOY_LICENSE_PAYMENT_TYPE',
    'DEPLOY_LICENSE_SUBSCRIPTION_EXPIRATION_DATE',
    'DEPLOY_LICENSE_CAN_RENEW_ONLINE',
    'META_INTERNAL_SERVICE_HOST',
    'META_API_KEY',
    'CASSANDRA_SCHEMA_VERSION'
);

foreach ($envs as $env) {
    $value = getenv($env);
    if ($value !== false) {
        $jsonValue = json_decode($value, true);
        define(
            $env,
            json_last_error() === 0
                ? $jsonValue
                : $value
        );
    }
}

Each listed and defined environment variable from above gets defined as a constant in php (by define(key, value). The only variable which was set in my setup was CASSANDRA_PORT. This had the following value: tcp://10.97.170.217:9042. I'm unsure where this value is getting set. I assume somewhere in testrail itself (php script files). This obviously is wrong. Basically because the variable is referring to a port but contains a full "address". Since all other environment variables where not set and I don't wanted to mess around with this environment variable for the whole system / container I decided to remove this from the task.php script only.
And this seems to work so far for me.