422 unprocessable entity when trying to create a block content

I attempted to replicate this. I gave the anonymous user the administer blocks permission so that I would have permission to POST a new block without any authentication.

I got the following response:

{
    "errors": [
        {
            "title": "Unprocessable Entity",
            "status": 422,
            "detail": "body.0.format: The value you selected is not a valid choice.",
            "source": {
                "pointer": "/data/attributes/body/format"
            }
        }
    ],
    "jsonapi": {
        "version": "1.0",
        "meta": {
            "links": {
                "self": {
                    "href": "http://jsonapi.org/format/1.0/"
                }
            }
        }
    }
}

Once I gave the anonymous role the "Use the Basic HTML text format" permission, I was able to successfully create the new block.

Does your user have that permission?

It's interesting that it's a 422 instead of a 403 though. That's interesting.

Did some digging.

Turns out this is a consequence of \Drupal\filter\Plugin\DataType\FilterFormat doing this:

  public function getSettableOptions(AccountInterface $account = NULL) {
    // @todo: Avoid calling functions but move to injected dependencies.
    return array_map(function ($format) {
      return $format->label();
    }, filter_formats($account));
  }

IOW: the options available are limited to those for the current account. But that is a semantically different thing: disallowed_format_name is a settable option, it's just not settable by the current user. If you'd pass nonsense as the format, it should be a 422, if you pass disallowed_format_name, it should result in a 403.

Oh, interesting! If that’s what’s happening, it would be very easy to add a failing test to JsonApiRegressionTest. There are lots of examples in there already. Could you add a test for this use case? 🙏

#6:

@Wim leers I found what is the issue, it was failing because there was already a block with the same name, lol, I tried different things, but I never thought that it could be the name. so is this expected? or Is a code when the entity already exists?

If that's really what's going on here, then that would be an important bug to fix, because if that's truly what's happening, you're getting the wrong validation error. Because \Drupal\block_content\Entity\BlockContent::baseFieldDefinitions() contains this:

    $fields['info'] = BaseFieldDefinition::create('string')
…
      ->addConstraint('UniqueField', []);

Which means you should get \Drupal\Core\Validation\Plugin\Validation\Constraint\UniqueFieldConstraint's error message, which is very different.

But in #8 you are getting that error response. So are you sure you're reporting things accurately here?

#8: That too sounds very strange. And indeed in all three scenarios you should get the same error message as that third scenario. Could you please add that scenario to JsonApiRegressionTest?

It doesn't make sense to me either that the first scenario would behave differently. The only reason I can think of that that would happen is that you have some contrib or custom module installed that does something special for uid=1.

It'd be great to know if you can reproduce this with "vanilla Drupal" (i.e. just Drupal core + JSON:API). If you can, it should also be easy to write a regression test (which I will then be able to do for you, unless you want to of course!).

Thanks for providing a regression test!

Indeed, thanks!

-'{"jsonapi":{"version":"1.0","meta":{"links":{"self":{"href":"http:\/\/jsonapi.org\/format\/1.0\/"}}}},"errors":[{"title":"Unprocessable Entity","status":"422","detail":"info: A custom block with block description Basic block 1 already exists.","source":{"pointer":"\/data\/attributes\/info"}}]}'
+'{"jsonapi":{"version":"1.0","meta":{"links":{"self":{"href":"http:\/\/jsonapi.org\/format\/1.0\/"}}}},"errors":[{"title":"Unprocessable Entity","status":"422","detail":"info: A custom block with block description Basic block 1 already exists.","source":{"file":"\/var\/www\/html\/modules\/contrib\/jsonapi\/src\/Entity\/EntityValidationTrait.php","line":59,"pointer":"\/data\/attributes\/info"},"meta":{"exception":"Drupal\\jsonapi\\Exception\\UnprocessableHttpEntityException: Unprocessable Entity: validation failed. in \/var\/www\/html\/modules\/contrib\/jsonapi\/src\/Entity\/EntityValidationTrait.php:59\nStack trace:\n#0 

Looks like the answer is clear though: one includes a stack trace, the other doesn't. They both result in the exact same error — fortunately! And they also both have an error object.

The problem you're running into is just that the block descriptions need to be unique.

However, you said that the error object was missing in some cases. Well … I think that just got fixed: #3042124: [regression] Empty response body when user is an administrator and an exception is thrown; some traces cannot be encoded because of recursion detection.. Could you please update to 8.x-2.x, commit 52534b2381c098a002075e4f3fadd9c998e0de8d and try again? Thanks!

It's now looking like this won't need an upstream bugfix.