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?

  • grrrr! Another bug in the simulator... After restarting it (which I tried multiple times since the problem) it was the same. But after I deleted all apps data, all apps and reseted the simulator, then restarted it, now it works again...

    I wonder though if this is only happening in the simulator....

  • -403 means it ran out of memory when processing the response.  When you get back json data and converted to a dictionary, it uses twice the memory or more.  If your app gets short of memory, you can see this,

    Or if your request does something that results in more data being returned, that will cause it.

    I've seen cases where doing a request that generates an error message, a non formatted message can cause this

    Log your makeWebRequests and when you have one with a -403, you can try doing that request in a browser to see what you get back.

  • If that wasn't clear, that's exactly what I did, that's how I know that the body was 5015 bytes. But it was the same before and the same after I resettled the simulator. And I think we can also rule out memory leak in my app, because then a simple restarting of the app (not even the simulator) would've fixed it. Also the peak memory usage is around 64k and fr965 has 128k memory.

    This is definitely something in the simulator

  • Are you sure the server wasn't having an issue that was resolved by the time you restarted everything?

    Why don't others see this unless they have a memory issue?

  • Yes. Why would it have problems only when I call it from the simulator, during something like 24 hours, but no problems when calling from curl from the same computer during the same time?

  • Again: what memory issues? Let's say my app have memory leak that eats up memory after a few hours. If this was the case simply restarting the app would fix it for a few hours. Besides my app would have memory problems which it doesn't, as the app continued to work as expected after getting tens of these -403 errors.

    So if there is any issue, that an app restart, and even a simulator restart doesn't fix, but deleting all aps from the simulator and resetting the simulator fixes, then the issue is in the simulator, don't you agree?

  • A memory issue is probably more common in a background service where you make a request, and what you get back needs double the memory to create the dictionary, where that maxes out the memory for a background service.

    Can you post a simple example that causes the -403?

    With the servers I use, I don't see -403 errors and I've been doing makeJsonRequests/makeWebRequests in the sim and on real devices for a decade, unless there's a bug in my code or something with the server.

  • Background: 1747002443 00:27:23 fetch: memory: free:41264, used:19992, total:61256
    Background: 1747002443 00:27:23 fetch: https://currentuvindex.com/api/v1/uvi => {latitude=>72.45, longitude=>67.12} // fake location, use yours :)
    Background: 1747002444 00:27:24 callback: memory: free:31736, used:29520, total:61256
    Background: 1747002444 00:27:24 callback: -403, data: null, ok:

    You'll see that the data is 5kB, so even if you need 4 times as much there's plenty of memory, even after the callback is called.
  • If you can recreate this reliably in the sim (seems like you can?) you could always try that trick some ppl are always suggesting, where you artificially increase the amount of memory available to the background process in the sim, for the device you are testing.

    At least that way you can try to validate that it doesn't fail if you increase available memory by a sufficient amount.

    Another thing you could is to make the same request in the foreground of a device app, and look at the peak memory in simulator vs the memory used when you're in the callback and valid data is returned, to determine what the actual overhead is for converting the data, in this case.

    Yeah, I know these are both super obvious approaches, but you could at least try to confirm or deny that it isn't something "normal" like actually running out of memory. Or if you're actually running out of memory (in the normal, unmodded background case), you could try to validate whether the peak memory seems too high (when doing the foreground test)

    I guess what I'm saying is there's a few possible explanations here for the -403 error:

    1) you're actually (in danger of *) running out of memory, but you shouldn't be (in this case, you would expect that increasing the available memory to the background would fix the problem, and checking the peak memory in a foreground version might show an unexpectedly high peak).

    2) you're not actually (in danger of) running out of memory, but something else is happening (in this case, you might expect that increasing the available memory to the background would not help)

    [* I say "in danger of" because if you literally ran out of memory, I would expect the background process to crash. But instead, it seems that makeWebRequest tries to prevent that from happening in the first place]

    In the case of 1), maybe there is simulator issue and it somehow causes too much memory to be used when converting a makeWebRequest response to a Monkey C dictionary? If you can make it fail / succeed on demand in the foreground test case, you could see if the corresponding peaks are significantly different.