Dealing with "GraphQL success but `data` is null" in storybook

I had a long battle with this error on my storybook.

Cannot render cell; GraphQL success but `data` is null

This happened in one my Page component calling a Cell component, with some-what developed mock data. Funny thing was the story for the Cell component was okay. It only triggered error when the page component rendered the cell component.

It was weird because the standard function in the mock file was called properly, but the Success component never got the data. Somehow it turned undefined during the delivery.

I looked all over, re-reading docs, tutorials, documents in msw, etc. I even tried versioning up and down @redwood – the project initially started at 0.24, and climbed up along the way. I was in 0.31.0 when I start tackling the issue, and tried upgrading to 0.31.2, which none actually helped.

So I finally launched a fresh project, and started adding console.logs and breakpoints in every possible places, and compared the differences.

The voyage started from the cell component, passed through @redwoodjs/createCell, and finally stopped at @apollo/client. It really had nothing to do with the msw library.

The problem was simple: MissingFieldError. I just hadn’t provide sufficient fields in my mock data! :sob:

While caching in apollo deals with partial results, it figures out what fields are currently missing and keeps the result-so-far into cache, and mark it as not ready for data yet. So even though there are no more queries executing, apollo won’t pass down the data, assuming there are something more going on.

The problem was that during the long-cycle of development, fields come and go, and I haven’t checked on every stories during the process. If I had confirmed each stories upon every migration, I would have found it sooner… but hey, sometimes there are much more busier things to do. And I now find that it comes with a price.

One thing interesting is that stories for cell components doesn’t seem to care, and do not throw any errors. As it renders each of the internal components in the cell, it does not seem to execute the graphql query. This got me lost in the wrong place for a while.

So while this is 100% user fault – that would be me – I feel that it’s so easy for someone else to get tripped over in the same spot – again, that could also be me. Slipping a field in mock data is such an easy mistake to make, and sadly the error messages does not give immediate understanding of the phenomena…


Great report and write up @jangxyz! Totally agree on the error being mysterious.

Hypothetical - what if the cell mock was typed?

Good point @danny.

In principle, that would give a much better indicator on having errors, as type errors are more revealing than failing stories.

The issue is that our team was re-using a loosely declared type from the api territory with several optional fields, and that’s where the missing fields were introduced.

I guess loose types happen here and there… still haven’t figured out everything on using typescripts with redwood. (To be honest, I haven’t been 100% confident with using typescript alone :slightly_frowning_face:) I’m seeing red curly lines on casual bases, and until I have the luxury of diving in for the endless search, I can’t help but leave it as they are.

Totally understandable - we’re working hard to bring full TypeScript support into Redwood, so definitely keep your eyes peeled - should help with identifying what red squiggles are an actual problem, and which ones aren’t really.

Thanks for posting this, really useful to get the insight (as with most things you share), and I’ll see what I can do with generated types to help with this process.

In terms of making the error better, could I ask you raise an issue on Github with an example (just code blocks will do) - it’ll help make sure it doesn’t drop off our radar


@danny Excuse me for stepping aside from the topic, but speaking of curly red underlines, how should we import cell components in being harmony with both typescript and babel?

I did follow issue#2205 thread, but couldn’t figure out what the conclusion is.

Currently I am manually wrapping createCell from the caller, since any other methods – not calling createCell at all, or calling it inside the cell component – gives weird outputs; ts complaining about not finding the default export, or babel raising errors about importing createCell twice.

Sure. Filed an issue here: Dealing "Cannot render cell; GraphQL success but `data` is null" errors · Issue #2473 · redwoodjs/redwood · GitHub

Definitely one of the things we’re looking to improve - also one that really bothers me personally. I don’t believe createCell is working as expected (I just tried it now), will be looking to fix this too.

For now only thing I can suggest is to add a ts-expect error with a searchable string


// @ts-expect-error: Cell Types not handled yet
import PetCell from 'src/components/PetCell'

So that you can remove these at a later date once we’re handling it on the Redwood side.


Thank you @jangxyz!!! I have had this same type of scenario and error for a while but couldn’t figure it out :see_no_evil: Now I know where to look :slight_smile:


For lost googlers:

This issue can happen outside of Redwoord as well. Empty data without error means that your probably listed some fields in your graphql fragment, but not in your mock response. For instance, I returned an array of results but forgot the totalCount that goes alongside!

This happens easily when you abstract your query generation process.

I haven’t yet found how to get this info in the result of a useQuery hook though.