This repository contains a minimal reproduction of apollographql/apollo-client#1186
.
Start the app by running yarn start
and then navigate to http://localhost:3000
You will be presented with a very simple app with buttons to select "evens" or "odds", which controls which list is loaded from a GraphQL endpoint to be displayed. We use pollInterval
to re-run requests every 4 seconds, and the server introduces an artificial delay of 2 seconds to each request, so a polling request should be in flight half of the time.
Open the network tab and monitor /graphql
requests. Two will be fired at a time (the reason for this is explained in the "Details" section below). If you change your "evens"/"odds" selection while the polling requests are in-flight, the container will get stuck in the loading state. Inspecing its data
prop in the React DevTools reveals that its data.networkStatus
value is stuck at 6
aka NetworkStatus.poll
which means that a polling request is in flight. This despite the fact that the polling request has finished, and subsequent ones even fire and complete without updating the component. If you change "evens"/"odds" while a request is not in flight, it will work and will even recover the app from the stuck state.
This issue seems to be caused by some interaction between polling, having multiple copies of the same GraphQL container component rendered on the page at a time, and triggering a re-render on the components while poll requests are in flight.
In order to reproduce this, the app is structured in a somewhat weird way. In particular, the List
component is rendered twice, regardless of your selection, but conditionally hidden based on selection. This issue does not reproduce if you remove the className
props passed to the List
component, which seems to suggest that this issue is triggered by something after this prop check in the react-apollo wrapper component.