Hey there!

My error output has asked me to file an issue with my failing subrequests, so I am here to do so, though I am sure that I am doing something wrong.

Here is the error output:

AssertionError: A Subrequests blueprint failed validation (see the logs for details).

Validation message:
Response failed validation: [{"requestId":"router","action":"view","uri":"\/router\/translate-path?path=some\/path"},{"requestId":"Page","action":"view","headers":{"Accept":"application\/json","X-CONSUMER-ID":"REALLYCOOLUUID"},"uri":"{{router.body@$.jsonapi.individual}}?include=field_content_sections.image,highlighted_content.field_image,field_content_sections.resource_file","waitFor":["router"]}]

And the failure reported:
Validation errors: [{"property":"[0]","pointer":"\/0","message":"Array value found, but an object is required","constraint":"type","context":1},{"property":"[1]","pointer":"\/1","message":"Array value found, but an object is required","constraint":"type","context":1},{"property":"[1].headers","pointer":"\/1\/headers","message":"Array value found, but an object is required","constraint":"type","context":1}]

It sounds like the issue is with my headers definition...but from what I can see, they are properly getting translated as an object.

This issue only seems to come up when I am running on my mac using Drush as the server, on my linux box running Lando, and on our Platform.sh instance, the same page request works fine. Here is the client code that is calling the route via axios:

    const routerRequest = {
        requestId: "router",
        action: "view",
        uri: `/router/translate-path?path=${params.vertical}/${params.slug}`
      };
      const pageRequest = {
        requestId: "Page",
        action: "view",
        headers: {
          Accept: "application/json",
          "X-CONSUMER-ID": process.env.CONSUMER_ID
        },
        uri: `{{router.body@$.jsonapi.individual}}?include=field_content_sections.image,highlighted_content.field_image,field_content_sections.resource_file`,
        waitFor: ["router"]
      };
      return app.$axios
        .post("/subrequests?_format=json", [routerRequest, pageRequest], {
          headers: {
            "Content-Type": "application/json",
            Accept: "application/json"
          }
        }).then(...

I am confident I am doing something funky here, but just wanted to report as requested.

CommentFileSizeAuthor
#5 3029570-subrequest-failed-validation.patch3.86 KBweemondo
#4 3029570-array-not-object.patch658 bytesweemondo

Comments

dustinleblanc created an issue. See original summary.

AdamWells’s picture

AdamWells commented

Hi, I was having the exact same problem and have figured out the issue with help from co-workers. I hope it's the same for you. In docroot/modules/contrib/subrequests/schema.json -- verify that the type property for your subrequest(s) and header(s) is an array instead of object. That fixed the issue for me.

"subrequest": {
      "title": "Subrequest",
      "description": "Contains all the necessary information to make the request.",
      "type": "array",
"headers": {
          "title": "Headers",
          "description": "HTTP headers to be sent with the request.",
          "type": "array",
AdamWells’s picture

AdamWells commented

Hi, I was having the exact same problem and have figured out the issue with help from co-workers. I hope it's the same for you. In docroot/modules/contrib/subrequests/schema.json -- verify that the type property for your subrequest(s) and header(s) is an array instead of object. That fixed the issue for me.

"subrequest": {
      "title": "Subrequest",
      "description": "Contains all the necessary information to make the request.",
      "type": "array",
"headers": {
          "title": "Headers",
          "description": "HTTP headers to be sent with the request.",
          "type": "array",
weemondo’s picture

weemondo commented
StatusFileSize
new 3029570-array-not-object.patch658 bytes

Same problem. In my case the schema validation is failing because it is expecting subrequests and headers to be objects but symfony serializer is by default returning associative arrays. I've attached a patch to change the schema which is the simple option if perhaps not the "right" one.

The Subrequest class expects headers to be an array, refactoring this is a little trickier than I have time for today, I will try to come back to this.

weemondo’s picture

weemondo commented
StatusFileSize
new 3029570-subrequest-failed-validation.patch3.86 KB

Adding a patch which decodes the json passing ['json_decode_associative'=> false]. This works locally with the given schema, but have not done extensive testing. This will decode the list of headers as an stdclass also, not sure if this will cause issues.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

Oh, it seems that the validator has changed the implementation under the hood.

dennis_meuwissen’s picture

dennis_meuwissen commented

I am running into the same issue with JSON:API and subrequests. Neither patches seem to work (anymore), so instead I've opted to disable validation for JSON:API responses until this gets resolved.

For those using a composer-based workflow, adding the following to your composer file will not install the Validator dependency used:

"replace": {
    "justinrainbow/json-schema": "*"
}

Since JSON:API checks to see if the Validator class supplied by the dependency exists before setting it (ResourceResponseValidator::setValidator), not installing the dependency simply ends up disabling the validation altogether.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Active » Needs review

Kicking the testbot awake.

weemondo’s picture

weemondo commented

Just about worked through the failed tests for the 2nd patch by casting arrays into objects. However, if there are any modules using subrequest data directly this could break the other modules (given that $request->headers is now an object).

I feel like I'm jumping through hoops so we can validate our php data according to json, which makes me wonder if there's a better way?

dustinleblanc’s picture

dustinleblanc
he/him/his
Primary language English
Location Ithaca, NY
commented

@weemondo I am not sure the best place to attack the issue, it seems @e0ipso mentioned the validator itself having a change. It's been long enough since I reported the issue that my mind is fuzzy about the issue and we ended up solving the problem for the project in a different way.

brian-c’s picture

brian-c commented

Just wanted to chime in here that a page cache issue caused both of the errors described in this ticket. Patch #2 at https://www.drupal.org/project/drupal/issues/3050383 resolved it for me.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Needs review » Closed (duplicate)
Dhammika’s picture

Dhammika commented

I can confirm if you skip the patches #4 and #5 AND patch with 3050383 (mentioned by Brian C above) AND bypass the validator as per comment #7, I was able to get a JSON-API request to be executed!

mattew’s picture

mattew commented
Category: Support request » Bug report
Status: Closed (duplicate) » Needs work

Still encountered the issue today. For me, disabling the JSON validator is not a real solution either an option, and I can't see how the page cache issue could be related to this JSON validation issue.

I can't see how today Subrequests could work out-of-the-box with this broken validator.

mattew’s picture

mattew commented
Status: Needs work » Needs review

The current simpler and safer way to fix this issue for the moment is using the patch #4. Works for me.

quadrexdev’s picture

quadrexdev
Location Lutsk
commented

The patch from #4 work for me. Thanks weemondo

  • e0ipso committed cf18716 on 3.x authored by weemondo 
    Issue #3029570 by weemondo, dustinleblanc, e0ipso, mattew, AdamWells,...
e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

Thanks for the contribution! Sorry it took this long.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.