Improve duckdb-wasm shell error message.

[douenergy]

What happens?

Follow #838 and #1243

Moving the error and warning messages from the console.log to the actual terminal in shell.duckdb.org will make it easier for users to see the errors and take necessary actions to fix them.

The rationale behind this suggestion is that it is more informative to have the error messages displayed in the same location as the code, rather than having to switch back and forth between the console and the code. By making error messages more visible and accessible, users can quickly identify and address any issues that arise while using the platform.

To Reproduce

reading some presigned url without proper CORS header setting

Browser/Environment:

Chrome 110

Device:

MacBook

DuckDB-Wasm Version:

1.24.1-dev40.0

DuckDB-Wasm Deployment:

shell.duckdb.org

Full Name:

Alex Tsieh

Affiliation:

None

[carlopi]

Thanks for opening this.

The implementation idea on this would be having console.warn (potentially console.log) be proxied on the WebWorker(s) so that first they would send the message to the main thread as it was a log item, and then forwarding to the regular console method.

var trueConsoleWarn = console.warn;
console.warn = function(args...) {
    // discover how to send message to main thread via postMessage
    trueConsoleWarn(arguments);
}

Improvement +1 would be having a separate MessageChannel dedicate to logging, and that would properly solve the multi-threaded case.

If someone wants to help out on this, it should be a relatively limited feature while gaining some insight on DuckDB-Wasm internals.

[shweta-singh-19]

Can I work on this ?

[carlopi]

You are very welcome to do so!

I will try to give some guidance later, basically you would need to look into packages/duckdb-wasm, there are 2 steps:

1. how to intercept console.log / console.warn ? (the function that perform the substitution needs to be executed only once!)
2. how to forge a Log message

This should be enough for this to be working, refinements are always possible later.

[shweta-singh-19]

Sure @carlopi

[shweta-singh-19]

@carlopi could you please guide me around how should I setup the local env to test the changes ?
Should i follow this readme ?
https://github.com/duckdb/duckdb-wasm/tree/master/packages/duckdb-wasm#readme

[carlopi]

Basics should be something like:
0. Install emscripten (CI uses 3.1.24, 3.1.34 also works), node and yarn (potentially other programs should be apparent)

1. make from within main duckdb-wasm folder shoud build all relevant steps
2. cd packages/duckdb-wasm-app
3. yarn run start
4. open a browser tab where prompted, you should see a self hosted shell deployment
5. trigger what was a silent warning
6. iterate

Feel free to share the current state you are at (say fork duckdb-wasm + push on your fork)

[shweta-singh-19]

Thank you@carlopi,

I have a linux system. I dont see this issue coming up on linux system. probably this is only specific on macbook.

here is the logs -

[carlopi]

Take for example this queries:

SET s3_region='us-east-1';
SET s3_access_key_id='xxx';
SET s3_secret_access_key='xxx';
select count(*) from read_parquet('s3://xxx/part-1.gz.parquet');

I see two errors logged in the JavaScript console via console.warn / console.error:

Access to XMLHttpRequest at 'https://xxx.s3.amazonaws.com/part-1.gz.parquet' from origin 'https://shell.duckdb.org' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
FAIL WITH: NetworkError: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://xxx.s3.amazonaws.com/part-1.gz.parquet'.

While only one get reported as InvalidError (the bottom one).
Ideally it would be useful also for the first to be logged.

Idea is that ANY error should be logged to the terminal, since this brings more informations to users (and allow to fix stuff faster).
Say that currently there is a memory access out of bound somewhere, in most cases it will not be shown, and that makes for a bad experience + becomes harder to understand what went wrong.

[carlopi]

This is the same issue basically, for more context: #110