Skip to content
This repository has been archived by the owner on Oct 23, 2023. It is now read-only.

sentry context not found on active domain #305

Open
smitt04 opened this issue Apr 13, 2017 · 6 comments
Open

sentry context not found on active domain #305

smitt04 opened this issue Apr 13, 2017 · 6 comments

Comments

@smitt04
Copy link

smitt04 commented Apr 13, 2017

I have a lot of errors not being reported. I am getting raven@1.2.1 alert: sentry context not found on active domain and no errors in the dashboard.

I think this has to do with nesting domains. My application already has a domain and requests go through it. In the middle i inject the requestHandler to get the sentryContext, but i then get these messages instead of the errors. It would be nice if i can attach a sentry context to my current domain instead of nesting them. When i looks at the active domain it sometimes has the sentryContext, but because of the way promises and domains don't play nice together i think it has trouble selecting the correct active domain during an error.

@LewisJEllis
Copy link
Contributor

LewisJEllis commented Apr 13, 2017

I think this has to do with nesting domains.

Definitely.

My application already has a domain and requests go through it. In the middle i inject the requestHandler to get the sentryContext, but i then get these messages instead of the errors.

Yep.

It would be nice if i can attach a sentry context to my current domain instead of nesting them.

Unfortunately no current facility for this, but seems reasonable for advanced use cases. I'll think about how to best do something like this.

Out of curiosity, could you share some more details on your use case/what you're already using a domain for, and how promises are fitting into this picture?

@smitt04
Copy link
Author

smitt04 commented Apr 13, 2017

I have written my own framework called sand. One of the modules for it is sand-http that builds on top of express and adds better routing and a MVC style to it. In order to keep everything working smoothly with the controller / actions and multiple other files we use domains to capture any errors and to create a request context so that no matter where you are in your app you can call sand.ctx and be in the current context for that request. It has req, res, sessions and any other info needed for the request attached to it. This way you don't need to pass req and res everywhere.

The promises are just used throughout the application to run asynchronous code. But it the past when using domains and promises i have had issue where you would not reenter a domain when the .then got called. you would have to use domain.bind on callback functions. Over the node versions this has gotten a little better as promises matured, but not 100%. Switching out your native promises for a library like bluebird tends to solve about 99.9% of issues with promises and domains.

@LewisJEllis
Copy link
Contributor

LewisJEllis commented Apr 13, 2017

so that no matter where you are in your app you can call sand.ctx

Makes sense, pretty similar to how we do contexts in Raven.

issue where you would not reenter a domain when the .then got called. you would have to use domain.bind on callback functions.

Yep, classic.

Over the node versions this has gotten a little better as promises matured, but not 100%. Switching out your native promises for a library like bluebird tends to solve about 99.9% of issues with promises and domains.

Out of the box this situation hasn't changed significantly AFAIK, but yea, bluebird generally solves it. We've had some discussion on that in #265.

Our getContext and setContext methods should still function properly despite that warning message, so it's more likely just a case of getting contexts mixed up due to our extra domain from requestHandler fighting with your existing one. Now that I think about it a little more, the problem is more from the requestHandler middleware than from whether we do or don't support hanging a Raven context off an existing domain other than our own (we actually pretty much do).

I don't know exactly what your domain-based error capturing you mentioned looks like, but what I can recommend trying based on assumptive/educated guesses:

  • Do Raven.disableConsoleAlerts() to turn those warnings off (context situation aside, we generally recommend doing once you've got everything set up and are pushing Raven to prod)
  • Ditch the Raven.requestHandler() middleware
  • Make sure wherever you're setting up your own domain with an error handler, you either
    • pass the error down express's next(err) pipe so Raven.errorHandler() sees it
    • or just do a Raven.captureException() right there

Our requestHandler middleware essentially boils down to doing something like:

var wrapDomain = domain.create();
wrapDomain.sentryContext = { ... };
wrapDomain.on('error', next);
wrapDomain.run(next);

Much simplified, but that's the core of it, to give you an idea of what's going on under its covers. It should be pretty straightforward to replicate that portion of its job in your existing domain error catching stuff, assuming that you have that set up along the lines of what I'm imagining.

@smitt04
Copy link
Author

smitt04 commented Apr 17, 2017

Sounds good, I will try it when i have a chance.

@geekguy
Copy link

geekguy commented Oct 11, 2017

@LewisJEllis - I see this error in our logs.

We are using pm2 and haven't used domains.

What might be the issue here?

@geekguy
Copy link

geekguy commented Nov 11, 2017

Any update on this?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants