Advertisement

Responsive Advertisement

Hacktoberfest 2026: What 7 Merged Kestra PRs Taught Me

Developer's laptop on a desk at night showing code in an editor, with a mug of coffee and orange autumn leaves nearby, for a Hacktoberfest 2026 post

Hacktoberfest ends tonight, and I'm going to say the quiet part out loud: the PR count is the least interesting thing about it. Still, I'm proud of mine. My Hacktoberfest 2026 run ended with seven merged pull requests across four Kestra repositories, and every one of them taught me something a tutorial never did.

This isn't a humblebrag post. Okay, it's a little bit of one. But mostly I want to show what contributing to a real open-source project looks like when you skip the typo-fix spam and actually try to be useful.

Why I picked Kestra for Hacktoberfest 2026

Kestra is an open-source orchestration platform. You describe workflows in YAML, and it runs them, schedules them and plugs into a huge list of services through plugins. It's the kind of tool data engineers use to glue APIs, databases and cloud storage together without writing a pile of cron jobs.

I signed up for Kestra's Hacktober program back on October 3. The appeal was simple. The project is big enough that a fix matters to real users, but organized enough that maintainers actually review your work. That second part is rarer than you'd think.

The seven PRs, in plain English

Here's the full list, oldest first. I'll keep it short, then get to the parts that were actually interesting.

That's my one list for this post, I promise.

The bug fix I'm proudest of

The Athena one is my favorite, and it's also the smallest idea on the list. When Athena returned a SQL NULL, Kestra's Query task still tried to convert the missing value into a number, date or timestamp. Those columns blew up with a parse error. Boolean columns were worse. They didn't crash at all. They quietly turned NULL into false.

Silent wrong data is the scariest kind of bug. A crash at least tells you something's off. A NULL that becomes "false" just sits in your report looking perfectly normal.

The fix itself is boring in the best way: check for null first, return null, and leave every other value alone. The real work was the test. I added one that feeds the task rows with NULLs across int, bigint, double, decimal, boolean, date, timestamp and varchar columns, and made sure it fails without the fix. A maintainer reviewed it and merged it on October 29.

What I learned from it

Maintainers don't want clever. They want a clear "before" and "after," a test that proves it, and a diff that doesn't touch anything it doesn't need to. My PR description was longer than the code change, and I think that's exactly right.

Blueprints that check their own homework

Four of my PRs went to Kestra's blueprints repo, which is basically a library of ready-made workflows people can copy and run. The repo has a strict checklist. You have to run the flow on a real Kestra 2.0 instance, call a real system (no faked results), use real plugin types, and keep secrets out of the YAML.

I leaned into public data APIs that don't need a key: Eurostat for inflation, NASA POWER for weather, and Energy-Charts for European electricity. Each flow loads the data, crunches it in DuckDB, and then does the part I care about most. It fails the run on purpose when its numbers don't match the published figures, or when the data window comes back empty.

That sounds like a small detail. It isn't. A pipeline that happily produces wrong numbers is worse than one that stops and yells at you. I tested those failure paths too, by tightening the tolerance until the check tripped, just to see it work.

The unglamorous PRs count too

The Azure PR was the most code, and nobody outside the project will ever notice it. Kestra's Azure plugin tests used to need a real Azure test account. I moved the Blob, Table, Cosmos DB and Event Hubs tests onto a single local emulator container, so you only need Docker to run them.

There was one gotcha. Cosmos DB's Java client defaults to a "direct" mode that talks to ports the emulator doesn't expose. So the client now switches to gateway mode when it isn't pointed at a real Azure endpoint, and real Azure keeps working exactly as before. I lost an embarrassing amount of time to that one.

And the Spark docs PR? It's eleven lines. It answers a question a confused user had about where SPARK_HOME comes from in the Docker image. Small docs fixes like that save strangers real hours, and they're a great first contribution if you're nervous.

Should you care about Hacktoberfest 2026 if you didn't join?

Honestly, yes, but not for the T-shirt or the badge. Here's my take.

If you're a student or a developer trying to get hired, merged PRs in a real project are better proof than another to-do app on your GitHub. Recruiters can click them. They can see the review comments. They can see you handled feedback without sulking.

If you're thinking "I'll wait for next October," don't. Most of what I did doesn't need a festival. Plenty of projects label beginner-friendly issues all year round. Pick one project, read its contributing guide twice, and ask to be assigned before you write code. That last step saved me from duplicate work more than once.

Where I'd push back is on treating it as a numbers game. Chasing a count tempts people to send junk, and maintainers burn out reviewing it. One solid fix beats five drive-by README edits every time.

What's next for me

I'm going to keep contributing to Kestra after today, probably on more plugin bugs, since that's where I felt most useful. I'm also spending time on my own open-source project, laya-ai, which is up on GitHub under the Apache-2.0 license. You can see everything I've been building on my GitHub profile.

FAQ

What is Hacktoberfest?

It's a yearly month-long event in October that encourages people to contribute to open-source projects. You can read the details on the official Hacktoberfest site.

Do I need to be an expert to contribute to Kestra?

No. Docs fixes and blueprints are a friendly starting point. Plugin bug fixes need some Java, but the existing tests show you the patterns to follow.

How long does a PR take to get merged?

For me it ranged from a few days to a couple of weeks. A clear description and a test that proves the fix made reviews much faster.

So here's my question for you: did you ship anything for Hacktoberfest 2026, or is open source still on your "someday" list? Tell me in the comments, I'd love to see your PRs.

Post a Comment

0 Comments