Aws-mobile-appsync-sdk-js: Combination of offlineDisabled=false & optimisticResponse prevents mutation response from being passed to update

[lklepner]

When the mutation is run with offlineDisabled=true the optimisticResponse will be sent to the update block first and when the server response is received it will be sent to the update block.

When the mutation is run with offlineDisabled=false the optimisticResponse will be passed to the update block twice even though the request was sent to the server and a response was received.

Sample code below. Any tips or workaround would be greatly appreciated.

  graphql(UpdateItem, {
    props: (props) => ({
      updateItem: ownProps => {
        props.mutate({
          variables: {
            id: ownProps.id,
            someValue: ownProps.someValue
          },
          optimisticResponse: () => ({ updateItem: { ...ownProps, __typename: 'SomeItemType', version: 1 } }),
          update: (dataProxy, mutationResult) => {
            console.log('dataProxy:', dataProxy)
            console.log('mutationResult:', mutationResult)  
          }
      }
    })
  })

aws-appsync: 1.3.3
aws-appsync-react: 1.1.3

[lklepner]

I had closed this issue thinking I had a serverside problem but upon closer inspect the original hypothesis seems to be hold up - server responses are never surfaced in the update as long as an optimisticResponse is present and offlineDisabled=false

[bvelasquez]

Having this issue also.

"aws-appsync": "^1.3.3"
"aws-appsync-react": "^1.1.3"

[ajmath]

I'm also seeing this. I have a use case where a mutation can only be executed while online and we need the body of the response before proceeding.

Here is the sample code:

const ConnectedAppScreen = (props: Props) => (
  <Mutation mutation={MutationGql} optimisticResponse={{ mutationName: DEFAULT_RESPONSE }}>
      {(mutation, { loading, error, data }) => {
        logger.info(`Got mutation update`, {loading, error, data});
        return (
          <AppScreen
            {...props}
            mutationResult={data}
            mutation={mutation}
          />
        );
      }}
  </Mutation>
);

When using offlineDisabled=true, the render prop is called with these args in sequence:

• data = undefined, loading = false (on load)
• data = undefined, loading = true (after invoking mutation function)
• data = { mutationName: { ... } }, loading = false (where data.mutationName is the response from the mutation)

When offlineDisabled=false, here is the behavior:

• data = undefined, loading = false (on load)
• data = undefined, loading = true (after invoking mutation function)
• data = { mutationName: DEFAULT_RESPONSE }, loading = false (immediately after getting the first loading response)

The expected behavior here is:
1) to have some indicator of the proper loading state of the mutation
2) to receive the updated response once it's returned from the server

I realize that this may go against the common usage pattern of mutations so maybe there could be some way to disable the offline capabilities for certain mutations? Any thoughts @manueliglesias?

[ajmath]

For the time being, I've worked around this by extending OfflineLink and checking for a context value that bypasses the offline link functionality.

class SkippableOfflineLink extends OfflineLink {
  public request(operation: Operation, forward: NextLink) {
    const ctx = operation.getContext();
    return ctx.skipOfflineLink ? forward(operation) : super.request(operation, forward);
  }
}

Getting this wedged into the appsync client required a custom implementation of createAppsyncLink which swapped out the OfflineLink implementation. @manueliglesias would you be open to accepting a PR with the "skipOfflineLink" functionality baked into OfflineLink?