Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: implements honeybadger.event by synchronous log call (#512)
* Implements Honeybadger.event by sync log call * API changes, add timestamp * fix #event: Use Hash() and reverse merge order. * feat: implement simple debug backend endpoint for events (#513) * Implement simple debug backend endpoint for events This currently is missing a queue and calls the backend directly from the agent. Should I implement an events_worker within this PR or in the PR that adds the server backend? * Refactor signature of events backend to take only one argument * WIP: Add worker * WIP start of worker spec * Worker spec successfully duplicated * Implement timeout mechanism using separate thread Given that the worker relies on the Queue as the main scheduling mechanism I saw no other way than to start a second thread that occasionally throws a message into the queue to check if the timeout is reached. This seems to work in testing. * Remove one timeout check, namespace config * Remove unused code * Add events worker to agent stop/flush commands * Fix debug message in events worker --------- Co-authored-by: Joshua Wood <josh@joshuawood.net> * Slightly bump sleep values in test to fix jruby tests There seems to be a slight difference in how sleep works in jruby so the timeouts in the tests did not hit predictably. * install sqlite dev package for rails tests * use sudo * Okay, sqlite problem seems to be based on rubygems issue sparklemotion/sqlite3-ruby#411 * I have no idea what I'm doing * feat: http(s) backend implementation for events (#520) * Implement simple debug backend endpoint for events This currently is missing a queue and calls the backend directly from the agent. Should I implement an events_worker within this PR or in the PR that adds the server backend? * Refactor signature of events backend to take only one argument * WIP: Add worker * WIP start of worker spec * Worker spec successfully duplicated * Implement timeout mechanism using separate thread Given that the worker relies on the Queue as the main scheduling mechanism I saw no other way than to start a second thread that occasionally throws a message into the queue to check if the timeout is reached. This seems to work in testing. * Remove one timeout check, namespace config * Remove unused code * Add server back end functionality for events This adds a minimal set of tests to ensure API conformance I've tested the code manually against "the real thing(tm)" * Add events worker to agent stop/flush commands * Fix debug message in events worker --------- Co-authored-by: Joshua Wood <josh@joshuawood.net> * Support Hash as first argument to Honeybadger#event (#521) This enables both signatures: # With event type as first argument (recommended): Honeybadger.event("user_signed_up", user_id: 123) # With just a payload: Honeybadger.event(event_type: "user_signed_up", user_id: 123) * Don't memoize events config The config is initialized after the agent is created (when the app loads). * Lazy initialize events worker This results in less change for current users—if you aren't using insights, the extra threads don't need to run. We could change this back in the future. --------- Co-authored-by: Joshua Wood <josh@joshuawood.net>
- Loading branch information
Showing
18 changed files
with
937 additions
and
4 deletions.
There are no files selected for viewing
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
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
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
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
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
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
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
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
Oops, something went wrong.