Skip to content
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

🚀 Que integration #361

Merged
merged 12 commits into from
Nov 13, 2017
Merged

🚀 Que integration #361

merged 12 commits into from
Nov 13, 2017

Conversation

tmiller
Copy link

@tmiller tmiller commented Nov 1, 2017

Description

Add instrumentation and exception reporting for Que.

  • Instrumentation is added by using meta programming around the Que::Job#_run.
  • Error reporting is implemented by passing an error handler to Que#error_handler since Que already handles exceptions.

@tmiller
Copy link
Author

tmiller commented Nov 1, 2017

I don't believe the exception reporting is working just yet, so please hold off on pulling this.

@tmiller
Copy link
Author

tmiller commented Nov 1, 2017

It seems to be working. I was running into problems because I was running the job synchronously, which doesn't not call _run but instead calls run directly so you can debug exceptions in the rails server or console.

@tombruijn
Copy link
Member

Hi @tmiller ,

Thanks for the PR!
Looks like it's using some outdated test suite setup. We're slowly trying to rewrite everything in issue #252 . I would like to rewrite the specs to use that before merging.

Also, do you have an example app you can share with us? Something we can add to this repo: https://github.com/appsignal/appsignal-examples

@tombruijn tombruijn changed the title Que integration 🚀 Que integration Nov 1, 2017
@tmiller tmiller force-pushed the que-integration branch 2 times, most recently from 0e04893 to b69f77b Compare November 3, 2017 21:39
@tmiller
Copy link
Author

tmiller commented Nov 3, 2017

@tombruijn I've made the changes, can you please review the changes to the tests? I am also working on setting up an example application as requested.

@tombruijn tombruijn self-assigned this Nov 6, 2017
@tombruijn
Copy link
Member

@tmiller That's great! Thanks for already updating the specs to use Appsignal::Transaction#to_h!
I'll review it and let you know if any further changes are needed.

Copy link
Member

@tombruijn tombruijn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tmiller I have some minor comments about the integration. Otherwise it looks really good! I'll see if I can set up an example app today, unless you already have one?

def install
require "appsignal/integrations/que"
::Que::Job.send(:include, Appsignal::Integrations::QuePlugin) unless
::Que::Job.included_modules.include?(Appsignal::Integrations::QuePlugin)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we only install the integration once so a check to see if the integration is already present shouldn't be necessary here.

transaction.set_error(error)
raise error
ensure
transaction.set_http_or_background_action(request.env)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if possible we want to minimize relying on this method. If we already know the class and method name combination in the integration itself, we can use Appsignal::Transaction#set_action instead.

In this case:

transaction.set_action "#{cls}#run"

Then the class and method name wouldn't have to be added to the request env on lines 11 and 12. Since this is not really a request, but a background job.

@@ -0,0 +1,172 @@
if DependencyHelper.que_present?
describe "Que integration" do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use the integration class name here?

Appsignal::Integrations::QuePlugin

@tmiller
Copy link
Author

tmiller commented Nov 8, 2017

@tombruijn
Copy link
Member

@tmiller That's amazing! I was just starting to set up an example app 😁

I'll try it out, test the integration you wrote and merge it into the examples repo

Let me know if you still have time to fix the comments I had earlier. If you don't have time, I'll push the fixes to this PR. After that I'll submit it to review for the rest of the team.

@tmiller
Copy link
Author

tmiller commented Nov 8, 2017

Thanks I have time, they will be done in a few minutes :)

wvengen and others added 11 commits November 8, 2017 10:10
Que catches all exceptions instead of rethrowing them to the caller.
This causes exceptions not to be logged in app signal. In addition to
adding the QuePlugin integration to Que, also set the error notification
handler so exceptions are logged to Appsignal.
QuePlugin is using Appsignal::monitor_transaction which setups up
exception handling, but Que already handles exceptions and has a
notifier that can be used to send excpetion to Appsignal.

This refactor removes the exception handling and the logic checking for
HTTP requests.
When using Transaction#set_action, we shouldn't need to set the class
and method in the request since this isn't a web request.
@tombruijn
Copy link
Member

@tmiller upon reviewing it against the example I noticed that ActiveJob is not tested in the test suite? I was trying something myself in this branch: https://github.com/appsignal/appsignal-ruby/tree/aj-que-integration
but so far have had no luck with it. Do you have any experience with testing it directly like so?

If this doesn't work we may have to revise the tests to only test the plugin itself without being included in the Que::Job class. I wouldn't want to have to add the postgresql dependency either.

@tmiller
Copy link
Author

tmiller commented Nov 8, 2017

We don't use ActiveJob. I think that was left over from the code before I picked it up. I haven't tried testing it, and I won't be able to work on adding tests and correct support for ActiveJob until Friday. I'm ok with removing the ActiveJob parts if you are?

@tombruijn
Copy link
Member

@tmiller we've discussed it here and we're okay with merging it without the ActiveJob support. I'd rather we take the ActiveJob logic out entirely and have another look at it in issue #330

@tmiller
Copy link
Author

tmiller commented Nov 9, 2017

Thanks! I've removed the code, anything else you need?

@tombruijn
Copy link
Member

@tmiller no, I think that's it! I've requested reviews from the team. Let's see if anyone else has any comments :)

@tombruijn tombruijn merged commit 6ef8dcf into appsignal:master Nov 13, 2017
@tombruijn
Copy link
Member

Thanks again @tmiller for the PR!
We'll try to release this in the upcoming 2.4.1 release. Which we hope will be sometime this week. It's waiting for PR #366 to be merged and tested.

@tombruijn
Copy link
Member

@tmiller this is now released in AppSignal gem v2.4.1 🎉

@tmiller
Copy link
Author

tmiller commented Nov 13, 2017

Thanks, for all the help!

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

Successfully merging this pull request may close these issues.

5 participants