prepare 3.2.3 release #17
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
modernize dev tools
Update babel config to work in `test` without `useBuiltIns`
initial move of code from js-client-sdk-private
use spread operator instead of Object.assign
add event capacity config property
re-add deprecation comment on samplingInterval
add event payload ID header
change exact dependencies to best-compatible
# Conflicts: # src/EventSender.js # src/__tests__/EventSender-test.js # src/__tests__/configuration-test.js
standardize linting
improve diag event tests + debug logging
# Conflicts: # package-lock.json # package.json
fix updating secure mode hash with identify()
don't omit streamInits.failed when it's false
clean up init state logic, prevent unhandled rejections
bwoskow-ld
approved these changes
Mar 6, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[3.2.3] - 2020-03-06
Fixed:
waitForInitialization()and provided an error handler for the promise that was returned by that method. While that is correct behavior if the application did callwaitForInitialization()(any promise that might be rejected should have an error handler attached), it is highly undesirable if the application did not callwaitForInitialization()at all-- which is not mandatory, since the application could use events instead, orwaitUntilReady(), or might simply not care about waiting for initialization. This has been fixed so that no such promise is created until the first time the application callswaitForInitialization(); subsequent calls to the same method will return the same promise (since initialization can only happen once).onoroffwhile handling an event. This has been fixed so that all event handlers that were defined at the time the event was fired will be called; any changes made will not take effect until the next event.