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

Feature Request: Change dsn at runtime #132

Closed
garthenweb opened this Issue Jun 30, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@garthenweb

garthenweb commented Jun 30, 2017

Our app requires changing the dsn at runtime between different hosts.
Raven allows changing the dsn by using the setDSN method.

I did not find any sane option to do this with react-native-sentry:

  • There is not setDSN method exposed
  • Sentry is a singleton which writes all configuration to its own instance, thus it's not possible to create multiple instances to choose in the app code which instance to talk to
  • There is no destroy method to clean the existing configuration up and create a new one

To integrate a setDSN function and delegate it to the RavenClient would be straight forward as far as I see, but to integrate it into the NativeClient would require implementing the functionality in the Android and iOS libraries which don't seem to be straightforward (at least to me).

It would be very nice to have this functionality. At the moment I am using a workaround where I ensure that the same Raven instance is accessable in the library and my app code to call the Raven.setDSN method before fireing events and disabled the native code. Sadly this is error prone and does of cause not allow us to use the native features.

It would be really cool to have this feature. In case the native clients would allow changing the dsn I also like to add a PR to react-native-sentry to implement it.
If you know any better workaround or if I missed something I would really appreciate your help.

@HazAT

This comment has been minimized.

Show comment
Hide comment
@HazAT

HazAT Jun 30, 2017

Member

Have you tried just calling install() again?

Member

HazAT commented Jun 30, 2017

Have you tried just calling install() again?

@garthenweb

This comment has been minimized.

Show comment
Hide comment
@garthenweb

garthenweb Jun 30, 2017

I thought about this, too. install creates some instances and event handlers, but will not clean them up when called twice.
I fear to have lots of Zombies in my code I can't control anymore. If there would be a way to graceful stop/ clear those instances, that might be an option!

garthenweb commented Jun 30, 2017

I thought about this, too. install creates some instances and event handlers, but will not clean them up when called twice.
I fear to have lots of Zombies in my code I can't control anymore. If there would be a way to graceful stop/ clear those instances, that might be an option!

@HazAT HazAT self-assigned this Jul 19, 2017

@HazAT

This comment has been minimized.

Show comment
Hide comment
@HazAT

HazAT Sep 21, 2017

Member

So update on this, we probably not gonna implement it since in a future Sentry version we want to make the environment a first level dropdown for projects.
I am not really sure what other use cases there are, except for different environments.
So there will be a different mechanism to handle this.

Member

HazAT commented Sep 21, 2017

So update on this, we probably not gonna implement it since in a future Sentry version we want to make the environment a first level dropdown for projects.
I am not really sure what other use cases there are, except for different environments.
So there will be a different mechanism to handle this.

@HazAT HazAT closed this Sep 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment