Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Watcher not firing after failure to decode response #3342

Closed
sameers27 opened this issue Feb 20, 2024 · 2 comments
Closed

Watcher not firing after failure to decode response #3342

sameers27 opened this issue Feb 20, 2024 · 2 comments
Labels
bug Generally incorrect behavior needs investigation

Comments

@sameers27
Copy link

Summary

In our usage, we use watchers as a source of truth for response handling. The setup is to start a watcher on load, fetch when needed, expect the watcher to fire when changes occur due to the fetch, and allow the watcher to process the response.

This allows us to ensure that any changes to the underlying objects due to auxiliary requests or changes occurring to the objects due to a fetch are all centralized in the watcher result handler.

One issue we've observed is that if we receive a decoding error on the initial watch (backend sends something unexpected), and we enter the failure block on the result handler of the watcher, the watcher will never fire again on subsequent fetches or changes where data received during the fetch is correct.

Version

1.9.0

Steps to reproduce the behavior

Here's an example watcher, query, and setup

query HomeQuery {
	home {
		sections {
			id
			name
		}
	}
}

func watchHome() {
	 homeWatcherCancellable = apollo.watch(query: HomeQuery(), resultHandler: { [weak self] response in
	 	switch response {
	 		case .success(let data):
	 			self?.home = data.home
	 		case .failure(let error):
	 			self?.failedWithError = error
	 	}
	 }
}

func fetchHome() {
	 homeFetchCancellable = apollo.fetch(query: HomeQuery())
}

func onLoad() {
	watchHome()
}

func refresh() {
	fetchHome()
}

Logs

No response

Anything else?

We also use a similar setup for subscriptions, where the watcher is responsible for handling the response.

@sameers27 sameers27 added bug Generally incorrect behavior needs investigation labels Feb 20, 2024
@AnthonyMDev
Copy link
Contributor

Hey there @sameers27. This does seem to be working as intended honestly. In order for the watcher to be able to watch for changes, it needs to get back the initial response, because that tells it what objects in the cache it needs to watch for changes on.

If your watcher is getting an error response form the server, the first thing I'd be concerned about is fixing whatever is causing that error (of course that's often easier said than done 😅).

Aside from that, if your watcher fails, you'll need to call it's refetch method and get a successful response for it to start actually watching those returned objects.

Theoretically, we could add something where the watcher watches for any successful response on the same exact query, but that's a departure from how they currently work. They are set up so that if the objects in the normalized cache change, from the same query or any other queries that happen to fetch the same objects, they will trigger. And for that, we are looking at the objects returned by the server, not the query operation that was sent.

If you would like to contribute that feature to query watchers, I would be happy to work with you on the design. But this isn't something that we plan on adding to our roadmap any time soon.

@AnthonyMDev AnthonyMDev closed this as not planned Won't fix, can't repro, duplicate, stale Mar 8, 2024
Copy link
Contributor

github-actions bot commented Mar 8, 2024

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Generally incorrect behavior needs investigation
Projects
None yet
Development

No branches or pull requests

2 participants