You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PFFile.getDataInBackgroundWithBlock not working with locally running parse-server #1481
I have a block of code that loads up images from PFFile.getDataInBackgroundWithBlock that seems to work just fine when I run the app going against the parse-server running on Heroku, however when I run the app against a locally running parse-server it does not work. I get an error that it has a network connection issue.
I have tried running it locally and going against the same mongoLab instance that is running on heroku as well as a locally running db and it is not working either way when I run it locally.
Is there a setting or something that I have to set to get this to work or is this a bug or some sort?
To help us debug this, can you include the exact request and response in Parse Server? (you can see this in the logs using VERBOSE=1 environment variable)
@drew-gross as I mentioned in my other post, I'm getting nothing extra in the logs when adding that flag. You mentioned something else may be wrong with my config, so this is the config that I'm using.
Then there is definitely not a bug in Parse Server. That flag causes every request to Parse Server to be logged, so if there are no logs, then your app can't connect to Parse Server. Check your network connection and make sure you aren't eg. initializing Parse with a localhost url on your iOS/Android device. If you still have issues, try asking on Stack Overflow or Server Fault.
It's definitely connecting to the parse-server instance. Everything else on my app is working fine and hitting the database, logging into facebook, etc. It's only when trying to get the file data in the background that it's giving me that error.
Okay so I got the verbose thing figured out - I was on an old version that simply didn't have it implemented. I now have it updated and it's obvious why it's failing.
Activity
astanton commentedon May 17, 2016
Anyone? I'm running into this again.
drew-gross commentedon May 17, 2016
To help us debug this, can you include the exact request and response in Parse Server? (you can see this in the logs using
VERBOSE=1environment variable)astanton commentedon May 18, 2016
@drew-gross as I mentioned in my other post, I'm getting nothing extra in the logs when adding that flag. You mentioned something else may be wrong with my config, so this is the config that I'm using.
Does anything look off about that that could be causing verbose to not work?
drew-gross commentedon May 18, 2016
Then there is definitely not a bug in Parse Server. That flag causes every request to Parse Server to be logged, so if there are no logs, then your app can't connect to Parse Server. Check your network connection and make sure you aren't eg. initializing Parse with a
localhosturl on your iOS/Android device. If you still have issues, try asking on Stack Overflow or Server Fault.astanton commentedon May 18, 2016
It's definitely connecting to the parse-server instance. Everything else on my app is working fine and hitting the database, logging into facebook, etc. It's only when trying to get the file data in the background that it's giving me that error.
drew-gross commentedon May 18, 2016
It might be an issue with the SDK then. Try opening an issue on the SDK's repo then.
astanton commentedon May 18, 2016
Okay so I got the verbose thing figured out - I was on an old version that simply didn't have it implemented. I now have it updated and it's obvious why it's failing.
"url": "http://localhost:1337/parse/files/myAppId/80e2ded0e303fe94bb14dc130683c71f_file.bin"It's trying to hit my localhost instead of the URL that I am tunneling through with ngrok.
So my question is, where would I set this flag so it goes to the ngrok IP instead of the localhost?
And this is on a device that I'm testing out on, not simulator.
EDIT:
Nevermind, keep this closed. PEBCAK.