-
Notifications
You must be signed in to change notification settings - Fork 115
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
Implement heartbeat checkins #1293
Conversation
Ensure that the stubs are called exactly once -- that is, that the same stub is not used several times, potentially masking a bug where several transmissions happen for the same events, and that no stubs are declared which are left unused. The strange way in which it is implemented is due to certain quirks of how the `webmock` gem works. I could not find a way to have a stub automatically disable itself when called, similar to what the `nock` Node.js package provides -- so I implemented this by passing a number of request bodies to expect to respond to when declaring the mock, and erroring if more requests are made than the request bodies provided. That, however, does not cover the scenario where the stub is not called at all. Somewhat bafflingly, the `have_been_requested` matcher does not check a counter that has been incremented for each request. Instead, it re-runs the requests it has stored by the stubs _again_, and counts how many match. Given the implementation described above, where the stub is exhausting a list of request bodies as it goes, the matcher will fail when attempting to go a second time around. So instead, we increment a counter when a request is processed (without said request having exhausted the matcher) and we return that counter from the stub. The tests store these counters in a `let` binding, and an `after` block checks that each stored counter has been increased to one. This is done in an `after` block not only for convenience, but because some tests are mocking a call that will only be performed in that same `after` block, when the scheduler is stopped.
2abbd5e
to
6077571
Compare
class RequestCounter | ||
attr_reader :count | ||
|
||
def initialize | ||
@count = 0 | ||
end | ||
|
||
def increase | ||
@count += 1 | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tombruijn could you take a look? I tried more reasonable approaches within webmock before reaching this count-requests-separately solution, but maybe I missed something in webmock that would solve this in a less awkward way
I'll take a look later. Your implementation seems to work, but a bit weird.
c5537ff
to
d20954b
Compare
This comment has been minimized.
This comment has been minimized.
d20954b
to
96bd3f6
Compare
Add an `Appsignal::CheckIn.heartbeat` helper that emits a single heartbeat for the check-in identifier given. When given `continuous: true` as the second argument, it spawns a separate thread that emits a heartbeat every thirty seconds. This is a convenience method for the use case where the heartbeat is only meant as a check that the process is alive. Split functions that deal with different event kinds out of the scheduler and test them independently.
96bd3f6
to
7ae7152
Compare
This comment has been minimized.
This comment has been minimized.
7 similar comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This is a message from the daily scheduled checks. |
Part of https://github.com/appsignal/integration-guide/issues/169.
Ensure stubs are called exactly once
[@tombruijn could you take a look? I tried more reasonable approaches within webmock before reaching this count-requests-separately solution, but maybe I missed something in webmock that would solve this in a less awkward way]
Ensure that the stubs are called exactly once -- that is, that the
same stub is not used several times, potentially masking a bug where
several transmissions happen for the same events, and that no stubs
are declared which are left unused.
The strange way in which it is implemented is due to certain quirks
of how the
webmock
gem works. I could not find a way to have astub automatically disable itself when called, similar to what the
nock
Node.js package provides -- so I implemented this by passinga number of request bodies to expect to respond to when declaring
the mock, and erroring if more requests are made than the request
bodies provided.
That, however, does not cover the scenario where the stub is not
called at all. Somewhat bafflingly, the
have_been_requested
matcherdoes not check a counter that has been incremented for each request.
Instead, it re-runs the requests it has stored by the stubs again,
and counts how many match. Given the implementation described above,
where the stub is exhausting a list of request bodies as it goes,
the matcher will fail when attempting to go a second time around.
So instead, we increment a counter when a request is processed
(without said request having exhausted the matcher) and we return
that counter from the stub. The tests store these counters in a
let
binding, and anafter
block checks that each stored counterhas been increased to one. This is done in an
after
block notonly for convenience, but because some tests are mocking a call
that will only be performed in that same
after
block, when thescheduler is stopped.
Implement heartbeat check-ins
Add an
Appsignal::CheckIn.heartbeat
helper that emits a singleheartbeat for the check-in identifier given.
When given
continuous: true
as the second argument, it spawns aseparate thread that emits a heartbeat every thirty seconds. This
is a convenience method for the use case where the heartbeat is
only meant as a check that the process is alive.
Split functions that deal with different event kinds out of the
scheduler and test them independently.