-
Notifications
You must be signed in to change notification settings - Fork 133
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
RUM-3574 perf: Start sending batches immediately after feature is initialized #1798
RUM-3574 perf: Start sending batches immediately after feature is initialized #1798
Conversation
25e7c0c
to
7afd568
Compare
Datadog ReportBranch report: ✅ 0 Failed, 2767 Passed, 0 Skipped, 6m 34.99s Wall Time 🔻 Code Coverage Decreases vs Default Branch (8)
|
Back to draft as the CI got flaky on BG tasks tests in |
by ensuring there is data available before worker is initialized. This is because we now start sending data soon after worker init.
I'm curious about the impact when a notification triggers app load and we will send anything pending all at the same time. |
As we discussed, we only change the delay of initial upload, so practically there won't be a change to the load spike in this scenario - it will be only shifted earlier in time. |
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.
👍
What and why?
📦⏱️ This PR removes the initial delay for sending batches. Now, first upload will be triggered soon after feature is initialized.
The motivation is to maximise a chance of sending data if application is impacted by early crash.
Related to DataDog/dd-sdk-flutter#573
How?
Removing initial delay from
DataUploadWorker
.Before:
Now:
Review checklist
Custom CI job configuration (optional)
tools/