when I ran through the loop against canvas production data, I ran into
a couple additional errors.
fixes CNVS-21542
test plan:
- try adding an external feed to a port that doesn't exist, like
localhost:9999
- add valid external feeds before and after that invalid one
- the valid feeds should still import, even though the invalid one will
fail
Change-Id: I4d0ef178ce18b9675d5138f3800dc9109fc97499
Reviewed-on: https://gerrit.instructure.com/57310
Tested-by: Jenkins
Reviewed-by: Benjamin Porter <bporter@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
we already handle external feed errors by incrementing a counter of
consecutive failures and only continuing to poll feeds with
< 5 consecutive errors.
fixes CNVS-20369
test plan:
- basic regression test of external feed functionality
Change-Id: I8d41729a4321bdacbb7ffa8a58495a1cafc0de48
Reviewed-on: https://gerrit.instructure.com/53833
Tested-by: Jenkins
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Adam Stone <astone@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
closes CNVS-6016
No more error reports! (soon)
this commit builds up sentry integration through the new
Canvas::Errors module, along with other things that need
to happen on every exception. ErrorReports
should now get pushed towards just being used for representing
a complaint a user filed via the get help form.
I fixed about half the things that got linted as well
while I was in here, but because this touches to much
I fear divergence from tackling too many (I think we
can safely say it's "better than we found it")
I left a lot of the infrastructure for error reports in place
until other commits for plugins can be merged
TEST PLAN:
1) setup your raven.yml config file with the dsn for our
sentry install
2) force an error to happen in a request response cycle.
3) see the error in sentry
4) force an error to happen in a job
5) see the error in sentry
6) statsd increments shoudl still fire
7) for the moment, an error report should still get created.
Change-Id: I5a9dc7214598f8d5083451fd15f0423f8f939034
Reviewed-on: https://gerrit.instructure.com/51621
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
instead of rolling our own request feed method, just use CanvasHttp,
which already supports https urls
fixes CNVS-17680
test plan:
- go to the course announcements page, add a feed with an https url
- in the console, set it's created_at to before the last post from the
feed
- run `ExternalFeedAggregator.process`
- it should work, creating a new announcements for the post
Change-Id: I43c48e3520a2129aad91e55ffa7aa8aa82e8814a
Reviewed-on: https://gerrit.instructure.com/46322
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Sean Lewis <slewis@instructure.com>
Tested-by: Jenkins
Product-Review: Simon Williams <simon@instructure.com>
external feeds have three columns that really aren't adding any value
* body_match: never used anywhere in the code, always nil in the
database
* feed_type: always 'rss/atom' (built to handle ical, but never used)
* feed_purpose: always 'announcements' (build to handle calendar_events,
but never used)
closes CNVS-17581
test plan:
- create an external feed on the announcements page
- wait for the rss feed to post a new story and the aggregator to run,
OR, in a rails console:
* set the created_at date on the external feed to before the last
posted entry, something like
ef = ExternalFeed.last
ef.created_at = 5.days.ago
ef.save!
* run the external feed aggregator, like so:
ExternalFeedAggregator.process
- it should create an announcement for the blog post from that feed
Change-Id: I74deffbdaaa1e217f8eefbdfd1000d50c2406cb1
Reviewed-on: https://gerrit.instructure.com/45990
Reviewed-by: Joel Hough <joel@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
this vastly improves performance when a root account has been deleted
also fix problem where skipped courses would cause the loop to run
indefinitely
Change-Id: I9c8ae5b1901abe5f59f3011ec8f433f06d7671b9
Reviewed-on: https://gerrit.instructure.com/44654
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
removed unused code to import an ical feed into a calendar,
and dropped the external_feed_id from the calendar_events
table because it isn't being used.
Change-Id: I9c093f4f2f63cc503d74bfc1cde089bf24ea0d73
Reviewed-on: https://gerrit.instructure.com/19615
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Eric Berry <ericb@instructure.com>
QA-Review: Zach Pendleton <zachp@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
refs #4487
This consolidates our ErrorReport class with our ErrorLogging mechanism,
it's all in ErrorReport now and you call ErrorReport.log_error or
ErrorReport.log_exception to both create an ErrorReport object, and call
the hooks similar to what ErrorLogging did so that plugins for other
error handling mechanisms can be injected.
ErrorReport has a category field now, similar to how ErrorLogging used
to take a type. the /error_reports UI can filter by category.
The plugin interface was designed with Hoptoad integration in mind, but
it should be pretty general.
Change-Id: I59f7a0d44cf4b6215ad13ff92d30e1d1af607b74
Reviewed-on: https://gerrit.instructure.com/3577
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Simon Williams