Currently, the way out watcher <-> server interact, the watcher's promise will "hold" it's state, until a future HTTP request reads it, this isn't a bug, but will absolutely trigger the unhandled rejection warning.
Although this isn't a bug, there is value in the unhandled rejection warnings being meaningful.
I can currently thing of some options:
a. create a faux promise that doesn't trigger the unhandled rejection warning; this would allow us to hide the warning, without breaking public API
b. have our watcher -> server promise, fulfill with a complex type{ value: unknown, type: 'FULFILLED', 'REJECTED' }; this allows the server full control, no warnings, but will also be a breaking change.
b. do something totally different; I don't really thing that is needed here.
I am currently out of time for this today, but will think about it more and hopefully resolve this issue soon.
Currently, the way out watcher <-> server interact, the watcher's promise will "hold" it's state, until a future HTTP request reads it, this isn't a bug, but will absolutely trigger the unhandled rejection warning.
Although this isn't a bug, there is value in the unhandled rejection warnings being meaningful.
I can currently thing of some options:
a. create a faux promise that doesn't trigger the unhandled rejection warning; this would allow us to hide the warning, without breaking public API b. have our watcher -> server promise, fulfill with a complex type{ value: unknown, type: 'FULFILLED', 'REJECTED' }; this allows the server full control, no warnings, but will also be a breaking change. b. do something totally different; I don't really thing that is needed here.
I am currently out of time for this today, but will think about it more and hopefully resolve this issue soon.