It’s tricky because when the isolate comes close to running out of memory, the garbage collector tends to work much harder, and as a result you tend to hit the CPU limit before the memory limit even though your problem is actually memory.
With that said, in practice, if you see error 1102, it is almost certainly from the CPU limit. These days when an isolate goes over its memory limit, we let it finish up in-flight requests before evicting it – unless it goes way over. So it’s actually hard to observe errors from hitting the memory limit.
Note that it’s common to see requests working correctly for a while, and then start throwing 1102. This is because we allow a worker to exceed its limit from time to time as long as it is not consistently over the limit. The enforced limit is 50ms (regardless of plan), so if you have a worker that runs for 60ms every time, it will succeed a few times and then start failing after awhile. TBH we should probably improve this so that the first few requests have strong enforcement and then let up a bit later on, so that errors are easier to see early…