A subtle bug with Go's errgroup

Summary

⏴ Back to all articles Published on 2025-08-09 A subtle bug with Go's errgroup Table of contents Yesterday I got bitten by an insidious bug at work while working on Kratos. Fortunately a test caught it before it got merged. The more I work on big, complex software, the more I deeply appreciate tests, even though I do not necessarily enjoy writing them. Anyways, I lost a few hours investigating this issue, and this could happen to anyone, I think. Let's get into it. I minimized the issue in a stand-alone program in just 100 lines. You can have a look at the real production code here if you are interested. After all, it's open source! Today, we are writing a program validating passwords. Well, the most minimal version thereof. It contains the old password, takes the new password on the command line, and runs a few checks to see if this password is fine: Checks if the new password is different from the old password. This can catch the case where the old password has leaked, we want to change it, and inadvertently use the same value as before. Which would leave us exposed. Check the Have I Been Pawned API, which stores millions of leaked passwords. This serves to avoid commonly used and leaked passwords. The real production program has a in-memory cache in front of the API for performance, but we still have to do an API call at start-up and from time to time. Check that the password is long enough For simplicity, the Have I Been Pawned API in our reproducer is just a text file with passwords in clear. One last thing: passwords are (obviously, I hope) never stored in clear, and we instead store a hash using a password hashing function specially designed to take up a lot of computational power to hinder brute-force attacks. Typically, that can take hundreds of milliseconds or even seconds (depending on the cost factor) for one hash. For performance, if we have to compute this hash, we try to do other things in parallel. To achieve this, we use an errgroup, which has becom...