Remi Broemeling

We just upgraded from v0.11.3 to v0.12.2 of the gem and were bit by a problem that looks very much like this: when our GitHub connection is initialized with a...

## github_cli sanity check ``` $ gcli repo branches USER REPO | fgrep ' name ' | wc -l 173 ``` ## Without setting .per_page on the connection ``` pry(main)>...

Hi @pete-stripe -- OK, great. Thanks. We've got a hackathon coming up at the end of this week, so I'll prioritize this up and see if I can get a...

If you would like me to rejig this so that the `ElasticacheReplicationGroup` struct only pulls in the field necessary (`ReplicationGroupCreateTime`), I am happy to do so. I was following the...

We're currently implementing Resque 1.24.1 on Redis/Redis-Sentinel in our environment, and this has bitten us pretty hard in our testing. By killing off a sentinel while Resque workers were active,...

OK. Is there a different file that I should issue a PR to? This was a critical problem for me -- it makes checking the value of the Redis "role"...

I just wanted to add in that we would also find this advantageous. Current messages look like: [project] - #7 Success after 51 min (Open) ... it would be great...

We've seen this behavior as well: a 307 Temporary Redirect is being treated as a failure by the dynect_rest gem, even though on the server side it is a success....

run_rate is currently set to 60 seconds, which aligns with our graphite configuration (one datapoint per minute). I'll try decreasing it to 30 seconds and report back with the result.

After making that change (to a run_rate of 30), I can still see areas where our upstream_response_time is noticeably higher than our request_time. For example:  I switched to a...