Closed unflxw closed 6 months ago
Ended up changing the design significantly, please re-review. I feel that heartbeat_with_context
was not a good name -- it was borrowed from send_error_with_context
, but "with context" in that function means "with this context for the error", not "by using a with
context block".
I feel that the current design, where the Heartbeat
class implements the with
context manager protocol, and heartbeat
can optionally be called with a function (in a way, doing both the Ruby API design and the Elixir/Node.js API design) is a lot clearer, and likely to be a better fit to most use-cases.
Also fixed some major issues with the implementation.
This is a message from the daily scheduled checks.
Store global client and expose its config
Store the last (hopefully only) initialised client in a global variable, and expose its config as a class method on the
Client
class.Implement AppSignal transmitter
Implement a transmitter module similar to the ones in other integrations, which handles the sending of requests with the usual AppSignal identifying params.
Remove empty
TYPE_CHECKING
blockProbably a leftover from some typing refactor.
Implement heartbeats for Python
Implement the heartbeats functionality for Python, similarly to how it was implemented for Ruby, Elixir and Node.js.
Due to limitations on how
with
blocks are implemented, which make it impossible for a function to behave in different ways when called "by itself" and when called by awith
block, it is possible to call it in the following ways:heartbeat(name)
, which sends a finish heartbeat eventheartbeat(name, function)
, which sends:with Heartbeat(name):
block (note:H
noth
!) which sends:with
block does not raiseAdd a
LOGGING_ENDPOINT
configuration variable to configure the logging endpoint, which is also the endpoint to which heartbeats are sent. This is a bit bizarre, as Python does not support the logging feature yet, but it is consistent with our other integrations.