Skip to content

fetchAllIfNeededInBackground error "Object not found on the server." #986

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

Closed
acegreen opened this issue Jul 20, 2016 · 14 comments
Closed

fetchAllIfNeededInBackground error "Object not found on the server." #986

acegreen opened this issue Jul 20, 2016 · 14 comments

Comments

@acegreen
Copy link

acegreen commented Jul 20, 2016

I'm running into an issue where I present a view and try to execute fetchAllIfNeededInBackground on a few objects. The first time the function is called, I get the mentioned error. Subsequent calls yields results.

Important note to make. This pointers in the "recentSearches" array can be from two classes.

    func getUserRecentSearches() {

        guard let currentUser = PFUser.currentUser() else { return }

        if let currentUserRecentSearches = currentUser["recentSearches"] as? [PFObject] {

            PFObject.fetchAllIfNeededInBackground(currentUserRecentSearches) { (currentUserRecentSearches, error) in

                if let currentUserRecentSearches = currentUserRecentSearches as? [PFObject] {
                    self.recentSearches = currentUserRecentSearches
                    self.tableView.reloadData()
                }
            }
        }
    }
@acegreen
Copy link
Author

acegreen commented Jul 20, 2016

It doesn't trigger the assertion below so objectId != nil

            PFParameterAssert(object.objectId != nil,
                              @"All objects must exist on the server.");

Additionally I followed the call stack a little and it seems to indicate 6 elements but only 5 objectIds. So it seems to fail on one but returns nothing? It should return at least 5.

That one object is probably of a different class (PFUser vs a PFObject)

screen shot 2016-07-20 at 1 16 00 pm

@acegreen
Copy link
Author

acegreen commented Jul 21, 2016

More notes:

  • fetchAllInBackground() also causes the same error AND it doesn't show results the second time around.
  • If the objects are all of the same class type, this error does NOT happen on first launch and the behaviour is as expected going forward

@acegreen
Copy link
Author

acegreen commented Jul 21, 2016

@nlutsenko I would appreciate your input on this. This maybe tied to #984 where I removed the assertion to be able to fetch from multiple classes at the same time.

@acegreen
Copy link
Author

acegreen commented Jul 21, 2016

My two guesses:

  1. Either by the second call, the first call is completed and it just brings up the cached results from the first call
  2. Since there are two classes in my case, the first call queried the objects for the first class and the second call for the second class and with that all the objects were found and returned

@shiva-wal
Copy link

seems like this is similar to my issue

@acegreen
Copy link
Author

acegreen commented Jul 21, 2016

@shiva-wal don't do that, don't hijack this thread

  1. Your issue is poorly written with no code samples or explanation to what you are trying to do
  2. findObjectsInBackground() is different than fetchAllIfNeededInBackground()
  3. I'm not returning an empty array but an error and I explained in detail why that seems to happen. So unless you are fetching from two classes or getting that error, it isn't similar.

Please remove your comment. And instead add details your issue.

@burf2000
Copy link

I think my issue is related to yours, hopefully we come up with a fix, spent all day trying to work out whats wrong, mine seems to be with relationships and fetchIfNeededInBackgroundWithBlock

@nlutsenko
Copy link
Contributor

Hey everyone,

What seems to be happening is that you are trying to fetch 6 objects, where only 5 have were found on the server. We explicitly fail with an error on that one and the entire task is treated as faulted (even though the 5 objects were successfully refreshed).

The first thing I would suggest checking is whether you can reproduce the same weird behavior with a simple curl request to isolate whether the issue is on the client or on the server (my gut says it's on the server). Also, enabling logging on the server could help observe whether a client makes the proper request.

Let me know what you find from the step above ^.

@parse-github-bot
Copy link

Thank you for your feedback. We prioritize issues that have clear and concise repro steps. Please see our Bug Reporting Guidelines about what information should be added to this issue.

Please try the latest SDK. Our release notes have details about what issues were fixed in each release.

In addition, you might find the following resources helpful:

@acegreen
Copy link
Author

acegreen commented Jul 22, 2016

@nlutsenko Thanks for the response. Regarding your points,

  1. All objects are on the server but
  2. There is at least one object that is of a different class (PFUser) than the rest, that may explain why the fetch seems to only find 5.
  3. The error only happens on first call, subsequent calls bring up the items just fine (all 6)
  4. If all objects are of the same class, there is no such error on first call.
  5. I have called this fetch with verbose, but can't post it here. The logs are printing in non-formatted so basically useless and the verbose on console is non-scrollable.
  6. I'm not savvy enough to attempt a curl request with the objects of a key in my user object. I did note thought that fetchAllInBackground does not give back any results even in subsequent calls.

Do you have an idea why a second call to fetchAllIfNeededInBackground the exact same data yields results?

The results the second time around seem to be cached, likely from the first time around.

screen shot 2016-07-22 at 6 10 07 pm

Based on the function above, we use the first objectId to determine the query class, can it be the cause? Since I have one pointer of a different class? if so, my question above would still be valid.

@acegreen
Copy link
Author

acegreen commented Jul 24, 2016

Just to point out, if I do the following on first call, the results appear from the get-go. Thats obviously because my call includes itself. So the first call is actually 2 calls in one.

    func getUserRecentSearches() {

        guard let currentUser = PFUser.currentUser() else { return }

        if let currentUserRecentSearches = currentUser["recentSearches"] as? [PFObject] {

            PFObject.fetchAllIfNeededInBackground(currentUserRecentSearches) { (currentUserRecentSearches, error) in

                if let currentUserRecentSearches = currentUserRecentSearches as? [PFObject] {
                    self.recentSearches = currentUserRecentSearches
                    dispatch_async(dispatch_get_main_queue(), { () -> Void in
                        self.tableView.reloadData()
                    })
                }

                self.getUserRecentSearches()
            }
        }
    }

@parse-github-bot
Copy link

This issue has not been updated for 7 days. If you have additional information to help pinpoint this issue as an SDK bug, please comment on this issue. We will close this issue in 7 days if no additional information is provided. Thank you for your feedback.

@parse-github-bot
Copy link

We are closing this issue due to another 7 days of inactivity. If you have additional information to help pinpoint this issue as an SDK bug, please reopen it with the additional information.Thank you for your feedback.

@flovilmart
Copy link
Contributor

There is at least one object that is of a different class (PFUser) than the rest, that may explain why the fetch seems to only find 5.

Yes and the code snipped you provided will run the query against the className of the first object, therefore marking the whole task as failed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants