Worker threads/signature verification pool tests #4089
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
| }) | ||
| parentPort.postMessage({ results, taskId }) | ||
| }) | ||
| ` |
There was a problem hiding this comment.
Ugh, there is likely no way around this "string-ification of code"? 😬 Or will there be a more "solid" way to do this later on? Anyhow - even if not - guess the price would be worth it. If the snippets are not getting too extensive.
There was a problem hiding this comment.
The pain point here is how worker threads work. The two ways to invoke worker threads are to pass the stringified code directly or invoke a separate file (e.g. worker.js). This issue shows how hard this once you integrate typescript into the equation. The worker thread environment doesn't inherit from the top level application so tsx doesn't run (or at least not easily). Nor do any of the tricks for having node run typescript directly. I spent a couple of hours thinking this through and my options are to either compile the code to Javascript (thus meaning we have js source files in our src directory (which is kinda weird) or I have to go the route suggested in the tsx issue and add this extra tsx/cli step to the thread loading step. Happy to go either way at this point.
|
Looks super-great! Love that this is already so structurally cleanly integrated, so that we can likely keep/merge even if we do not follow up on this directly. At least I would ad hoc suggest - that we do permanently keep such a code struct as test setup, so that we can do more easily do future experiments with other code parts and have the outer stuff already in place. 🤩 Maybe for this we could just move over the "production" code from Two small direct nice-to-have suggestions:
|
44dc6a2 to
a6b2eb2
Compare
A vibe coded experiment with worker threads for ecrecover