The issue is that querying the blocks field on StructBlock leads to error message.
Before I update to the version from GitHub, this seemed to be related to ImageChooserBlock inside the StructBlock and if they have a value or not. But I have tested this now with and without and ImageChooserBlock as a field in the StructBlock and the behavior remains the same.
A query like this
query {
page(slug: "first-article"){
id
... on BlogPage {
freeformbody {
... on StructBlock {
id
blocks {
id
}
}
}
}
}
}
[29/Jul/2020 05:17:36] "POST /graphql HTTP/1.1" 200 141242
Traceback (most recent call last):
File "<...>/.venv/lib/python3.7/site-packages/promise/promise.py", line 489, in _resolve_from_executor
executor(resolve, reject)
File "<...>/.venv/lib/python3.7/site-packages/promise/promise.py", line 756, in executor
return resolve(f(*args, **kwargs))
File "<...>/.venv/lib/python3.7/site-packages/graphql/execution/middleware.py", line 75, in make_it_promise
return next(*args, **kwargs)
File "<...>/.venv/src/wagtail-grapple/grapple/types/streamfield.py", line 150, in resolve_blocks
block = child_blocks[field["type"]]
graphql.error.located_error.GraphQLLocatedError: string indices must be integers
When removing the blocks field from the query, then the response works successfully.
Here is the part of the page definition this issue seems concerned with.
Hi,
I have just installed the latest Grapple version from master (which should already include https://github.com/GrappleGQL/wagtail-grapple/pull/82). Since it mentioned #54 which was also concerned with the
StructBlock
https://github.com/GrappleGQL/wagtail-grapple/pull/54#issuecomment-604432979, I thought I would help my issue here. Turns out that is not the case.The issue is that querying the
blocks
field onStructBlock
leads to error message.Before I update to the version from GitHub, this seemed to be related to
ImageChooserBlock
inside theStructBlock
and if they have a value or not. But I have tested this now with and without andImageChooserBlock
as a field in theStructBlock
and the behavior remains the same.A query like this
leads to an error like that:
And here is the output on the server side:
When removing the
blocks
field from the query, then the response works successfully.Here is the part of the page definition this issue seems concerned with.
I assume this has something to do with the serialization of the
StuctBlock
child fields.Are you able to reproduce this behavior?