{"push_id":606642411,"size":1,"distinct_size":1,"ref":"refs/heads/flush-retry-recovery","head":"a381b3667d81dbdfc0aae557b22260eba8e4e1fa","before":"191d91285a0fe74187917998ef7615f3836bc98f","commits":[{"sha":"a381b3667d81dbdfc0aae557b22260eba8e4e1fa","author":{"email":"3a2deb47b4342b32af1d40b75a7391f40aa3d3f3@gmail.com","name":"Evan Huus"},"message":"producer: bugfix for aggregators getting stuck\n\nIn circumstances where Flush.Messages and/or Flush.Bytes were set but\nFlush.Frequency was not, the producer's aggregator could get stuck on a retry\nbecause a metadata-only chaser message would not be enough on its own to trigger\na flush, and so it would sit in limbo forever.\n\nAlways trigger a flush in the aggregator when the message is a chaser. This has\nthe additional benefit of reducing retry latency when Flush.Frequency *is* set.\n\nAdd a test for this case.","distinct":true,"url":"https://api.github.com/repos/Shopify/sarama/commits/a381b3667d81dbdfc0aae557b22260eba8e4e1fa"}]}