makeWebRequest suddenly returns -403

I am working on a new feature that uses 2 web requests. I am testing it for about a week both on a real fr965 and in the simulator. It worked pretty well until yesterday, when in one of the web requests I started to get -403. The response is relatively big (content-length: 5015) but it wasn't a problem until yesterday on the fr965 (It was on some older devices in the simulator). What could have changed?

Top Replies

flocsy🤠 9 months ago in reply to flowstate +1

Wow, surprize!
before web request: memory: free:218920, used:39584, total:258504
in the beginning of the callback; memory: free:196048, used:62456, total:258504

So from this I'd guess that the amount of memory…

All Replies

flocsy🤠 9 months ago in reply to flowstate

Wow, surprize!
before web request: memory: free:218920, used:39584, total:258504
in the beginning of the callback; memory: free:196048, used:62456, total:258504

So from this I'd guess that the amount of memory used is around 13kB, but according to the memory viewer:

current use: 38.1kB, peek use: 79.1kB, so here it suggests that 41kB more is used at the peak than after all the processing of the response is finished. All this is to parse a 5kB json that comes from a public api, so I can't reformat / optimize it. But I'll look into it further, because it still doesn't explain why it works at the beginning and then stops working after a few hours.

And another surprize: back to making the web request in the background app, just ran the app now in a simulator window that was opened not long ago for the purpose of trying the above in the foreground app and it reproduced the problem just now, while the memory usage in the background app is:

before web request: memory: free:41168, used:20088, total:61256
in the callback: free:31640, used:29616, total:61256
and because the problem happens, the responseCode is -403 and the data that is being sent to the callback is null

DaveBrillhart 1 day ago in reply to flocsy🤠

FWIW - I just ran into a -403. I added some lines as I converted various sub elements to null out the no longer needed part of the data. my BG free memory ended up much larger and the 403 error was eliminated. I could have probably just put the data = null; just before the Background.exit().... but this worked.

// progression

outExit["lo_tload"] = data["progression"]["tl"]["ftp"];

outExit["hi_tload"] = data["progression"]["tl"]["hie"];

outExit["pk_tload"] = data["progression"]["tl"]["pp"];

outExit["lo_rload"] = data["progression"]["rl"]["ftp"];

outExit["hi_rload"] = data["progression"]["rl"]["hie"];

outExit["pk_rload"] = data["progression"]["rl"]["pp"];

data["progression"] = null;

// ir params

outExit["lo_ttau"] = data["ir_params"]["ftp"]["tau1"];

outExit["hi_ttau"] = data["ir_params"]["hie"]["tau1"];

outExit["pk_ttau"] = data["ir_params"]["pp"]["tau1"];

outExit["lo_rtau"] = data["ir_params"]["ftp"]["tau2"];

outExit["hi_rtau"] = data["ir_params"]["hie"]["tau2"];

outExit["pk_rtau"] = data["ir_params"]["pp"]["tau2"];

data["ir_params"] = null;

Background.exit(outExit);

flocsy🤠 1 day ago in reply to DaveBrillhart

If I understand correctly then what you did is:

1. makeWebRequest ->

2. callback:

3. - remove some parts of the response

4. - Background.exit

And you say that removing the parts in 3 prevents the -403 error in 2?

Is that what you claim?

Did you always get the -403 or the 1st request was ok and it only happened later? Because I find it hard to believe that the watch knows at 2 what will you do at 3. The only plausible explanation I can think of is that the way Background.exit serializes and passes the data to the foreground has an effect on the memory and that affects the LATER web requests.