HactoberFest's Week 3: Fixing a Type-Casting Issue in Kestra’s Chunk Pebble Filter

Introduction

This week, I decided to take on a slightly more challenging issue in Kestra, a powerful open-source workflow orchestration platform. Kestra is a huge project with a complex codebase that spans multiple plugins, filters, and workflow types. Its size and complexity made it both intimidating and exciting, the perfect opportunity to learn more about backend systems, Java, and workflow orchestration while contributing to open source.

I specifically chose this issue because it involved a core filter in the Kestra Pebble templating engine, which is widely used in user flows. Working on this would allow me to understand a critical part of the system and contribute something meaningful to the platform.

The Issue

The issue I worked on was tracked in Kestra as Issue #12090. It involved the chunk Pebble filter, which is used to split a list into smaller chunks based on a given size.

The problem occurred when a workflow passed the size parameter as an integer. The filter expected a Long internally, so Java threw a type-casting exception, causing the workflow to fail.

For example, consider a workflow that attempts to chunk a list:

variables:
  max_items: 2

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: |
      {% set x = [1,2,3,4,5] | chunk(vars.max_items) %}
      {{ x }}

In this case, vars.max_items is an integer. When the chunk filter tried to use it, it resulted in a runtime type-casting error because it expected a Long.

Getting Started

To fix this issue, I first set up the Kestra project locally. This was challenging because the project has multiple modules, a Maven build system, and numerous dependencies. Understanding the project structure was critical before touching the code.

Once I had a working development environment, I located the ChunkFilter.java file and examined how the filter processed the size argument. I also reviewed the existing unit tests to understand the expected behavior.

The Fix

The solution involved updating the ChunkFilter to handle any Number type for the size argument instead of strictly expecting a Long. The changes included:

• Modifying ChunkFilter.java to accept any Number type.
• Adding a runtime check to ensure that the size argument is indeed a number.
• Converting integers to long internally to maintain compatibility.

After implementing the changes, I tested the filter locally with both integer and long values in sample flows to confirm correct chunking behavior. Once satisfied, I committed the changes and submitted a pull request:

PR #12148 – handle integer size in chunk Pebble filter

Writing Test Cases

The maintainers asked me to write test cases that would reproduce the original issue. This was an exciting learning opportunity because it required me to think like a tester:

• I wrote unit tests simulating workflows with integer and long sizes.
• Verified that chunking worked correctly in all cases.
• Submitted the tests along with my PR.

The maintainers provided suggestions to improve the tests, and I implemented them. This iterative process helped me understand both testing best practices and the importance of collaboration in open-source contributions.

Challenges and Learnings

Working on this issue was more challenging than previous weeks:

• Understanding the entire process of a Pebble filter and how it interacts with user flows.
• Navigating a huge codebase and identifying the exact location of the bug.
• Writing robust tests to cover edge cases and reproduce the original issue.

However, it was also very rewarding:

• I learned how to handle type-casting issues in Java effectively.
• Gained confidence in modifying a critical core component of a large project.
• Experienced firsthand the PR review process, including implementing feedback and improving my contributions.

Reflection

This week showed me again why I enjoy contributing to open source. Even though the bug was technical and needed careful work, fixing it, testing it, and getting feedback from the maintainers was really exciting. It also made me more confident to take on bigger and more complex issues in the future.

I’m excited to continue exploring more projects and contributing more substantial fixes and features in the coming weeks. Each contribution, no matter how small, is a step toward mastering backend development and becoming a better open-source contributor.