When Mixpanel.alias is used it creates it's own default Consumer instance and sends the event through it. This makes it ignore any custom configuration done on the side of a Consumer.
Usecase
The Scaling your server side tracking docs suggest implementing a custom consumer that logs the events into one file/stream and then send the events outside of main thread to not make the event sending synchronous with the application.
But since it's always a good idea to have secrets, such as Mixpanel token, in as fewer places as possible we decided to log the events with a placeholder token and replace it only before they are actually being sent to the Mixpanel servers. This approach makes it so that .alias method is not working at all.
I do get the idea that alias has to be created before any events with the new id are tracked (#7). But the current implementation is a bit too binding and unintuitive from the perspective of the library user.
When
Mixpanel.alias
is used it creates it's own defaultConsumer
instance and sends the event through it. This makes it ignore any custom configuration done on the side of a Consumer.Usecase
The Scaling your server side tracking docs suggest implementing a custom consumer that logs the events into one file/stream and then send the events outside of main thread to not make the event sending synchronous with the application.
But since it's always a good idea to have secrets, such as Mixpanel token, in as fewer places as possible we decided to log the events with a placeholder token and replace it only before they are actually being sent to the Mixpanel servers. This approach makes it so that
.alias
method is not working at all.I do get the idea that alias has to be created before any events with the new id are tracked (#7). But the current implementation is a bit too binding and unintuitive from the perspective of the library user.