-
Notifications
You must be signed in to change notification settings - Fork 213
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
feat(crons): initial cron support #661
Conversation
// CaptureCheckIn captures a check in. | ||
func (client *Client) CaptureCheckIn(checkIn *CheckIn, monitorConfig *MonitorConfig, scope EventModifier) *EventID { |
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.
There was a discussion in Discord (#off-topic) between me and @cleptric about what function name to implement (as the PHP and Node implementation is quite different), where Michi suggested to follow the PHP implementation as the event is the check in already. As for Go SDK, if this implementation folows PHP's, this would be something like:
event := &sentry.Event{
// fill payloads
}
event.SetCheckIn(checkInPayload)
eventId := sentry.CaptureEvent(event)
It's kind of awkward and confusing for me, so I went ahead with the CaptureCheckIn
as a method of Client
struct.
interfaces.go
Outdated
// The fields below are only relevant for crons/check ins | ||
|
||
CheckInID string `json:"check_in_id,omitempty"` | ||
CheckIn *CheckIn `json:"check_in,omitempty"` | ||
MonitorConfig *MonitorConfig `json:"monitor_config,omitempty"` |
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.
If I follow how transactions are keeping their data, it would mean that every entry on CheckIn
would be spread out and might mess with other fields in the future, so I keep it enclosed here with omitempty
tag.
interfaces.go
Outdated
if e.MonitorConfig != nil { | ||
checkIn.MonitorConfig = &MonitorConfig{} | ||
checkIn.MonitorConfig.Schedule = e.MonitorConfig.Schedule | ||
checkIn.MonitorConfig.CheckInMargin = e.MonitorConfig.CheckInMargin | ||
checkIn.MonitorConfig.MaxRuntime = e.MonitorConfig.MaxRuntime | ||
checkIn.MonitorConfig.Timezone = e.MonitorConfig.Timezone | ||
} |
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.
Yes I know it looks bad. It's 10 PM on Tuesday and I can't think of anything better right now. So sorry 🙈
Thanks @aldy505 , we'll have a look this/next week 👍 |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #661 +/- ##
==========================================
+ Coverage 80.49% 80.70% +0.20%
==========================================
Files 42 44 +2
Lines 4333 4416 +83
==========================================
+ Hits 3488 3564 +76
- Misses 717 724 +7
Partials 128 128
☔ View full report in Codecov by Sentry. |
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.
Overall looking good 👍
Left some comments, but nothing super major.
client.go
Outdated
// CaptureCheckIn captures a check in. | ||
func (client *Client) CaptureCheckIn(checkIn *CheckIn, monitorConfig *MonitorConfig, scope EventModifier) *EventID { | ||
event := client.EventFromCheckIn(checkIn, monitorConfig) | ||
return client.processEvent(event, nil, scope) |
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.
Let's maybe make it consistent with other Client.Capture* methods.
return client.processEvent(event, nil, scope) | |
return client.CaptureEvent(event, nil, scope) |
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.
I'll have to reread the code before committing the suggested changes. I don't remember if it's okay to call that method from here.
Co-authored-by: Anton Ovchinnikov <anton@tonyo.info>
Co-authored-by: Anton Ovchinnikov <anton@tonyo.info>
Co-authored-by: Anton Ovchinnikov <anton@tonyo.info>
Co-authored-by: Anton Ovchinnikov <anton@tonyo.info>
I'll address any errors on CI in a few hours. |
Failures on Windows can be ignored for now, seems like it's only a test that has been flaky recently. |
// The status of the check-in. | ||
Status CheckInStatus `json:"status"` | ||
// The duration of the check-in. Will only take effect if the status is ok or error. | ||
Duration time.Duration `json:"duration,omitempty"` |
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.
What I realized is that we don't have an option to pass an existing CheckInID
via CheckIn
now.
At the moment we basically create a new CheckInID every time, so there's no way to link the "in-progress" and "ok"/"error" status.
Could you handle this case please?
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.
Done. I might want to add a test case for this one, or an example.
Another thing that we'll have to do eventually is to update the docs, basically adding Go to this list: https://docs.sentry.io/product/crons/getting-started/ |
Thanks a lot @aldy505 👍 🎉 |
Closes #659
This implementations looks up to: