worker errors cannot be catched

[bugzpodder]

repo: https://bugzpodder.pyscriptapps.com/polyscript-worker-errors/latest/
source code: https://pyscript.com/@bugzpodder/polyscript-worker-errors/latest
micropip throws an error because of missing package but it cannot be caught in main thread

[WebReflection]

This is what I read ...

[Error] Origin https://bugzpodder.pyscriptapps.com is not allowed by Access-Control-Allow-Origin. Status code: 404
[Error] Failed to load resource: Origin https://bugzpodder.pyscriptapps.com is not allowed by Access-Control-Allow-Origin. Status code: 404 (json, line 0)
[Error] Fetch API cannot load https://pypi.org/pypi/foofoofoofofofsfs/json due to access control checks.
[Error] Failed to load resource: Origin https://bugzpodder.pyscriptapps.com is not allowed by Access-Control-Allow-Origin. Status code: 404 (json, line 0)
[Error] Unhandled Promise Rejection: PythonError: TypeError: invalid exception object

	hiwire_throw_error (pyodide.asm.js:9:20535)
	<?>.wasm-function[292]
	(anonymous function) (pyodide.asm.js:9:75747)
	onRejected (pyodide.asm.js:9:58950)

accordingly, it looks like your server headers don't allow CORS nor COI, COOP, and CORP

[WebReflection]

about the main thread, these are network errors generated at the pyodide level ... as that dance is async, I am not sure these errors should be propagated to the main from a worker, specially because there's no default place to show these errors.

The console though is there to tell you what's going on but I agree we might find a better solution to error reporting for this case, it's just that users complained about errors shown on the main recently, so we need to be careful about how we should proceed here (planned as topic).

[WebReflection]

P.S. there is a mini-coi service worker script that works most of the time, I suggest you use that for your tests.

[WebReflection]

P.S.2 the headers for workers is documented in here: https://pyscript.github.io/polyscript/#enabling-xworker
if you find ways to improve such documentation please let us know, thank you!

[bugzpodder]

hmm not sure what happened, CISCO suddenly started blocking pyscriptapps.com and it happens in the last 60 minutes, so I can no longer access the link myself... (generated from pyscript.com, the headers for XWorker should be set properly). I've updated the initial post with the source code.

In general, in worker.py we have:

async fn():
  ... throw an error ...
  
sync.fn = fn

in main thread I am doing:

try {
  await xworker.sync.fn();
} catch (e) {
   // never gets run
}

My expectation is that if fn throws an error it would be caught in the main thread but it doesn't happen. I had to try/catch in worker.py and handle the error explicitly.

[WebReflection]

what does sync.fn() returns? I am not sure errors should be propagated as return value simply because they throw in pyodide (or any other interpreter) so I expect you to have, at least, an error in console ... right?

[WebReflection]

in short I am saying we can't wrap foreign WASM callback execution out of the box and the dance between main and threads knows nothing about foreign WASM callback executions ... curious to know what happens though, as we might intercept that and forward back when that happens, not ideal, neither simple, but maybe possible ...

on the other hand, it looks like you are trying all possible edge cases out there ... I mean: shouldn't that error be handled in Python code instead and produce whatever error you expect?

[bugzpodder]

in short I am saying we can't wrap foreign WASM callback execution out of the box and the dance between main and threads knows nothing about foreign WASM callback executions ... curious to know what happens though, as we might intercept that and forward back when that happens, not ideal, neither simple, but maybe possible ...

on the other hand, it looks like you are trying all possible edge cases out there ... I mean: shouldn't that error be handled in Python code instead and produce whatever error you expect?

thanks. This is exactly what I am doing, intercepting the error in python and calling xworker.sync.handleError() and I am fine with the status quo. However I am pointing out that in javascript land, other polyscript users (like myself initially) would naively expect try/catch around await xworker.sync.fn() should work in javascript land in main-thread but in reality the error doesn't seem to propogate here.

Happy with just a simple documentation update in polyscript somewhere.

[WebReflection]

expect try/catch around await xworker.sync.fn() should work in javascript land in main-thread but in reality the error doesn't seem to propogate here.

errors throws, don't propagate cross realm ... they throw in the realm ... we can try to wrap that but the point is that you do see an error in console, and that's from the realm it belongs to ... the rest is magic that waits to have more issues filed around it.

[WebReflection]

I feel like this can be closed as we're discussing error in another issue that got closed too.

[bugzpodder]

example: https://bugzpodder.pyscriptapps.com/xworker-sync-hangs-when-raise-error-copy/latest/

worker python function raises an error. the main thread awaits this function and it never finishes await (hangs). I don't remember if we specifically discussed this issue or decided that it can't be addressed. Let me know if you want me to file a new bug

[WebReflection]

you should see errors in the devtools console, right?

[bugzpodder]

yes i do see exception. I guess by doing

   await xworker.sync.funcThatThrows();
} catch (e) { console.log('im here')}
console.log('continue on');

i was expecting the error to be caught and the execution continues on but this is not the case.
anyway the work around is to always try/catch every sync function on the python side..

[WebReflection]

I think errors should propagate but invoking worker stuff from main is not a primary use case for us ... it's going to be fixed at some point though. We're releasing, there's focus on other things.