zalando

A Tiny Regex Bug in Adyen's Java Library, and How My Fix Shipped in SDK v42.0.0 In my last posts I wrote about why I started open source and about my first merged PR in Zalando Logbook. This one is about a PR in the Adyen Java API Library, and it is a good example of how a very small bug can hide in plain sight. What is the Adyen Java library? Adyen is a global payments company, and this library is how Java applications talk to Adyen's APIs. The whole SDK has to build the correct base URL for every service, for both test and live environments. If that URL is wrong, the payment call goes to the wrong place. The bug The method createBaseURL in Service.java swaps test URLs for live URLs. It used String.replaceFirst() to do that. Here is the catch: replaceFirst() takes a regex, not a plain string. In regex, a dot . means "any character". So a URL part like pal-test.adyen.com was not matching a literal dot. It was matching any character in that position. Simplified, it looked like this: // Before: the dots are treated as "any character" because this is a regex url = url.replaceFirst("pal-test.adyen.com", "pal-live.adyen.com"); For normal URLs it worked fine, which is exactly why nobody noticed. But a URL that only looks similar, with other characters where the dots should be, could still be transformed by mistake. The fix The fix was small. I replaced the affected replaceFirst() calls with String.replace(), which matches plain text with no regex at all: // After: plain literal matching, no regex wildcard risk url = url.replace("pal-test.adyen.com", "pal-live.adyen.com"); I updated the pal-, checkout- and device-api- blocks. I left the two calls without dots (-live to -test and back) as replaceFirst() on purpose, because they were not affected by this issue. I also added a test, testLivePalUrlOnlyMatchesLiteralDots(), using a URL shaped like pal-testXadyenYcom. It looks like the real endpoint but has no literal dots, so it must not be transformed. The test proves the fix and protects against the bug coming back. What the review taught me - Keep the scope tight. The maintainer said he thought about asking me to use .replace in the other places in the method for consistency. Then he decided it was not necessary, because it was unclear whether that would cause some other issue. A good reviewer is careful about changes that were not asked for. It reminded me to fix the bug I was given, not everything I could. - Formatting is part of the PR. The project had recently enforced code formatting, and my PR was blocked until I ran mvn spotless:apply. A tiny thing, but it taught me to run the project's formatter and checks before pushing, every time. - Tests are the real proof. My first version of the test was not strong enough, and I improved it so the URL structurally matched the real one with non-dot separators. A test should fail without your fix, otherwise it proves nothing. The PR was approved and merged, and the change shipped in SDK v42.0.0. Seeing something I wrote inside a release of a payments SDK was a good feeling. The change was small, but real people who use the library get it. What I would tell someone starting out 1. Small bugs are good first PRs. You do not need a big feature to make a real contribution. 2. Read the project's contributing rules and run its formatter and tests before you push. 3. Write a test that fails without your fix. 4. Do not widen the scope. Fix what the issue asks for. Proof of my work Everything here is public, so you can check it yourself: - Adyen/adyen-java-api-library #1952: the regex fix (merged, shipped in v42.0.0) - The original issue #1838 - zalando/logbook #2301: StatusCodeBasedSink and LevelBasedHttpLogWriter (merged) - PicnicSupermarket/error-prone-support #2275: merged after review - Sionna Visualizer: my side project, a 6G + AI dashboard (live demo) - My GitHub: all my repos and contributions Next post: my PR in Picnic's error-prone-support, and what working with a strict reviewer taught me. If you are a maintainer, a recruiter or a team looking for someone who learns in public and likes to collaborate, my DMs are open. Tell me in the comments if you have hit a regex surprise like this one.

My First Merged PR in Zalando Logbook: What I Built and What the Review Taught Me In my last post I wrote about why I started open source. This post is about the first PR that got merged for me in a big project: Zalando Logbook. What is Logbook? Logbook is a Java library from Zalando that logs HTTP requests and responses. If you work with REST APIs, you know why this matters. When something breaks in production, the first thing you want to see is what request came in and what response went out. What I worked on My PR added two things to Logbook: - StatusCodeBasedSink: a sink that makes decisions based on the HTTP status code of the response. - LevelBasedHttpLogWriter: a log writer that uses the status code to pick the log level. The simple idea behind both: a 200 response and a 500 response should not be treated the same. Errors should stand out, and normal traffic should not fill your logs with noise. It got merged in May 2026. You can see the full PR, the code and the review here: zalando/logbook #2301 How I approached it I did not start by writing code. I started by talking to the maintainers on the issue, so I knew what they wanted before I built anything. Then I kept the change small and focused, wrote tests, and signed my commits. Looking back, that order saved me a lot of pain. Writing code first and asking later is how PRs get stuck. What the review taught me Maintainers read very carefully. They do not only check if your code works. They ask: - Does this fit the style of the project? - Will this break anyone who is already using the library? - Is the naming clear for someone who has never seen this code? Answering those questions made my code better than my first version. Reviews are slow sometimes, but they are free teaching from people who know the codebase far better than I do. The part I did not expect After my PR was merged, another contributor found a gap in my own work. The ECS sink did not follow the same status code behavior, so he opened an issue and then a PR to fix it. My first feeling was a little embarrassing. But then I thought about it properly: this is exactly how open source works. Nobody ships perfect code. So instead of rushing to send a competing PR, I reviewed his one and left comments on the threshold behavior and on the docs checklist. You can read that discussion here: zalando/logbook #2379 That was a good lesson for me: reviewing someone else's PR is also a contribution, and it teaches you how others think. What I would tell someone starting out 1. Read the issue and talk to the maintainer first. 2. Keep your PR small. A small diff gets reviewed faster. 3. Take every review comment seriously, even when it feels strict. 4. If someone finds a gap in your work later, treat it as part of the process, not as a failure. What is next In the next post I will write about my PR in the Adyen Java API Library, which shipped in SDK v42.0.0, and how it felt to see my change in a real release. Proof of my work Everything I write about here is public, so you can check it yourself: - zalando/logbook #2301: StatusCodeBasedSink and LevelBasedHttpLogWriter (merged) - adyen/adyen-java-api-library #1952: shipped in SDK v42.0.0 (merged) - PicnicSupermarket/error-prone-support #2275: merged after review - Sionna Visualizer: my side project, a 6G + AI dashboard (live demo) - My GitHub: all my repos and contributions If you are a maintainer, a recruiter or a team looking for someone who learns in public and likes to collaborate, my DMs are open. Tell me in the comments if you work with Logbook or want to contribute to it, I am happy to share what I learned.

One log level for every HTTP response? Too noisy 🔍 Logbook logged every response at one level. My PR sets it by status: 2xx → TRACE, 4xx → WARN, 5xx → ERROR. Merged into @Zalando Logbook 🚀 logbook#2301 #Zalando #Java #BackendDeveloper #OpenSource

Colored HTTP logs in the console 🎨 Logbook’s pretty-printed JSON was plain text. My PR adds ANSI colors for local dev, so it’s easier to read. PR open at @ZalandoTech , in discussion 💬 logbook#2385 #Zalando #Java #BackendDeveloper #OpenSource

A nice set of guidelines for developing Restful APIs. Provided by Zalando. zalando/restful-api-guidelines

Java’s HttpClient body can be read only once 🔍 Logging it can break the real request. My Logbook PR copies the body as it streams. PR open at @ZalandoTech , review in progress 🛠️ logbook#2386 #Zalando #Java #BackendDeveloper #OpenSource

tech-radar ⭐ 1.9k A D3.js visualization of a technology radar for developers and teams tracking technology adoption. 🔗 zalando/tech-radar #opensource t.co