-
Notifications
You must be signed in to change notification settings - Fork 162
👷 change e2e implementation for workers #3901
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Bundles Sizes Evolution
🚀 CPU Performance
🧠 Memory Performance
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage 🔗 Commit SHA: 9afa674 | Docs | Was this helpful? Give us feedback! |
createTest('service worker with worker logs - esm') | ||
.withWorker() | ||
.withLogs() | ||
.withWorker( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to move this to the createTest? So that we do something like:
.withWorker({ isModule: true, handleMessageWith: 'logger' })
Similar to what we do in:
.withExtension(createExtension(path.join(BASE_PATH, name)).withRum().withLogs()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the idea is to avoid that scenario and be more generic, or that's what I understood from @bcaudan feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could make the API more convenient by:
- providing a function to
withWorker
, to work directly with code instead of a block of text - have the worker implementation as complete as possible:
- let it import the script rather than handle that in workerSetup, it would be easier to follow
- provide it the consolidated configuration
to be able to do something like:
.withWorker((config) => {
import '/datadog-logs.js'
// Initialize DD_LOGS in service worker
DD_LOGS.init(config)
// Handle messages from main thread
self.addEventListener('message', (event) => {
const message = event.data
DD_LOGS.logger.log(message)
})
})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bcaudan I had this as an earlier version, but then I found that the current implementation is closer to what we do with Logs/RUM (withLogs
and withRUM
).
0feb678
to
a5b8ded
Compare
// Handle messages from main thread | ||
self.addEventListener('message', (event) => { | ||
const message = event.data; | ||
DD_LOGS.logger.log(message); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ question: Do we need to use post message for every test? Could we instead have the log needed for the test be triggered when the worker is started from the worker implementation?
It would reduce the complexity of those tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bcaudan I thought about it, and it's a bit tricky, because it means the test it auto-executes it. Are you ok with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my understanding the test would instantiate the worker and this instantiation could generate the log use case that we want to test, avoiding the extra message exchanges with the main thread.
Was there any issue that this message exchange was preventing or any other issue that you see with the "auto-execution"?
if not, I'd say it is worth a try.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we do it with other tests as well?
Motivation
The initial implementation of Worker E2E tests was somewhat tied to our specific use case and will not scale if we need to test different scenarios within the Worker environment.
Changes
It introduces a version of
withWorker
that automatically sets up the logs inside the worker. We can also pass an implementation, similar to what we do withwithLogs
andwithBody
.Test instructions
All e2e still passed.
Checklist