CommentClientError now has sane subclasses that are meaningfully
distinct, and each subclass is handled appropriately. Errors raised by
the requests library are no longer handled by turning them into
CommentClientErrors, since there is no meaningful handling we can do,
and this way we will get more visibility into why errors are occurring.
Also, HTTP status codes from the comments service indicating client
error are correctly passed through to the client.
Logging the duration of each request will allow us to determine
whether there is a significant difference in the latency reported by
the comments service and that observed by the LMS. Each request will
be assigned a unique identifier to allow correlation of the reported
latency on each end.
Previously, authentication was done using a URL parameter, which would
appear in various logs. Now, authentication is done more appropriately
with an HTTP header. Note that this requires cs_comments_service commit
cf39aabdd160176ebf206ca19d3ee030161a0b47 or later.
According to someone from Datadog, this was generating tags like "knowledgeable_
people_who_put_this_course_together._this_is_harvard._you_can_t_tell_us_there_s_
a_shortage_of_editorial_talent." They say that they can handle tens or hundreds
of unique tags but not thousands. Given that we have a unique URL for each
thread, we can't even use that as a tag. Thus, all tags are removed for now
until we can determine whether there is a useful set of tags with small enough
cardinality. In light of this, I did not investigate why the long tag mentioned
above was being generated.
The LMS comment client previously would try to parse the response
as JSON, choke, and return a 500 to the client. Now, the LMS client
displays a message indicating that the forums are down for
maintenance.
