When I try to import a simple configuration I get an error "An error occurred while processing with arguments:" Steps to recreate, Enable the rest and basic_auth modules and then import the following yml content in admin/config/development/configuration/single/import. I selected "Simple Configuration" for the Configuration type and Configuration name value is rest.settings
----------------------------------
resources:
entity:node:
GET:
supported_formats:
- json
supported_auth:
- basic_auth
POST:
supported_formats:
- json
supported_auth:
- basic_auth
PATCH:
supported_formats:
- json
supported_auth:
- basic_auth
DELETE:
supported_formats:
- json
supported_auth:
- basic_auth
link_domain: ~
-------------------------

Once I click on import I get the above mentioned error. But the configurations seems to imported without any issue because the rest call seems to work.

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

nmeegama created an issue. See original summary.

nmeegama’s picture

Version: 8.1.x-dev » 8.1.2
anavarre’s picture

Got the same error message when trying to import a flag and a flag-based view. Note that I didn't get the error on vanilla 8.2.x but only on an already existing site running 8.1.2 - Couldn't say if it's related or not for now.

luizsgpetri’s picture

Same error importing a content type: An error occurred while processing with arguments

The content type is imported event with the error.

anavarre’s picture

Title: Error message on rest.settings single import » Importing a view throw An error occurred while processing with arguments
Version: 8.1.2 » 8.4.x-dev
Issue tags: -Drupal 8.x, -REST API
anavarre’s picture

Title: Importing a view throw An error occurred while processing with arguments » Importing configuration (e.g. views, content type) throws An error occurred while processing with arguments
ExTexan’s picture

We get this error quite frequently. I've never noticed that the configuration update(s) were not successful.

Looking at the finishBatch process, perhaps $success isn't getting set to TRUE in some cases, even if the import process completes without errors.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

macjules’s picture

Version: 8.5.x-dev » 8.3.7
Issue tags: -Configuration system +Configuration Synchronization

Steps to reproduce;

1) Export a view and copy the code
2) Delete that same view
3) Navigate to /admin/config/development/configuration/single/import
4) Select 'View' as Configuration type
5) Paste view code into 'Paste your configuration here'

View imports ok but returns system message "An error occurred while processing with arguments:".

There seems to be some confusion on the finishBatch as to what is a $success, $success with $results['errors'] and a failure. The above steps produce a $success (no errors reported) so should not that at least report $success? Instead I am seeing it treated as a failure to import.

  public static function finishBatch($success, $results, $operations) {
    if ($success) {
      if (!empty($results['errors'])) {
        foreach ($results['errors'] as $error) {
          drupal_set_message($error, 'error');
          \Drupal::logger('config_sync')->error($error);
        }
        drupal_set_message(\Drupal::translation()->translate('The configuration was imported with errors.'), 'warning');
      }
      else {
        drupal_set_message(\Drupal::translation()->translate('The configuration was imported successfully.'));
      }
    }
    else {
      // An error occurred.
      // $operations contains the operations that remained unprocessed.
      $error_operation = reset($operations);
      $message = \Drupal::translation()->translate('An error occurred while processing %error_operation with arguments: @arguments', ['%error_operation' => $error_operation[0], '@arguments' => print_r($error_operation[1], TRUE)]);
      drupal_set_message($message, 'error');
    }
  }
ExTexan’s picture

Adding to #9, that may be reliable steps to reproduce this issue (and that's great), but I want to point out that it isn't the only condition causing the error. In none of the cases where we've encountered that bug have we ever copy/pasted individual config settings. We always export everything, and import/sync everything. Just sayin'.

sean_e_dietrich’s picture

I've ran into this issue recently where I'm using standard Drush to do the config export and drush to do the config import. Mainly my issues is that it doesn't seem to like the fact I am including datetime as a required module.