I’m glad to continue sharing my open-source journey through this third update of Hacktoberfest! In my previous blog, I talked about my earlier pull requests in the Cloudinary community projects, how my fixes got merged, and what I learned from the feedback process. This week brought a few more interesting developments, deeper technical challenges, review discussions, and contributing to different repository.
Continuing the Work with Cloudinary
As discussed in my last post, I had worked on Issue #232 and created a corresponding Pull Request #241.
This issue was about the generative fill feature failing for images larger than 25 megapixels. I fixed the problem by first transforming such large images down to the required pixel limit before applying any other transformations. This approach solved the immediate bug, the plugin no longer failed, but as I later discovered from the review comment, it also had an unintended side effect.
The reviewer explained that while my fix worked for the fill-background plugin, the same issue could appear in other plugins that use Cloudinary’s AI-based features such as gen_restore, gen_remove, gen_recolor, and gen_replace. In short, there was a deeper architectural issue, and my fix needed to be more generic.
Since I’m still new to this project, I didn’t want to rush into implementing a wide-ranging solution without proper guidance. I replied to the comment asking for direction on how to handle this in a scalable way. For now, I’m waiting for feedback from the maintainers before moving forward. It’s a great reminder that sometimes, fixing one bug can uncover a much bigger design consideration and that collaboration is key to solving it right.
Follow-Up Issue and Easy PR
The next related task came from the Next-Cloudinary repository — Issue #592.
As you can see in this comment, the maintainer asked me to upgrade the dependencies to reflect the fixes I had worked on in cloudinary-util.
So, I created PR #636, which simply upgraded the @cloudinary-util/url-loader and @cloudinary-util/util packages in the project’s package.json and reinstalled them using pnpm install. It was a straightforward change, but it ensured the latest bug fixes were included in the Next-Cloudinary SDK. Sometimes, even small updates like this help keep the ecosystem consistent and reliable.
Exploring a New Repository – OpsiMate 💡
After finishing my work on the Cloudinary repositories, I decided to explore another open-source project to broaden my learning experience. That’s when I came across OpsiMate, an open-source platform that helps organizations manage operations, providers, and facilities efficiently. It’s built using a modern stack of TypeScript, Express, and React, which gave me a chance to understand how backend validation and database logic work in real-world projects.
While going through the repository, I found Issue #251, which addressed a bug allowing users to create multiple providers with the same name and type—for example, two “Test” VM providers. This caused confusion and potential data issues. The expected behavior was that the application should prevent duplicates and show a clear error message.
To fix this, I created Pull Request #535, titled “[FIX]: Added UNIQUE constraint to database and error handling to the server for duplicate providers.” In this fix, I enforced the validation directly at the database level by adding a UNIQUE(provider_name, provider_type) constraint to the providers table schema. I also introduced a custom DuplicateProviderError class, updated the business logic to catch this specific error, and modified the controller to return an HTTP 409 Conflict response whenever a duplicate provider is detected.
This change ensures that even if multiple users try to create a provider with the same name and type at the same time, the database automatically blocks the duplication. It’s faster and more reliable than manually checking in the application code. Now, when a user tries to add a duplicate, the system shows a clear message saying “Provider with name ‘test’ and type ‘VM’ already exists.”
I verified this locally by first creating a provider named “test” under the Server type and then trying to create another one with the same name. The system immediately returned the conflict message, confirming that the fix worked as intended. Since this update involved a schema change, I deleted the existing opsimate.db file and recreated the database to apply the new constraint. I’ve also asked the maintainers for guidance on how this should be handled in development and production environments.
This contribution taught me the importance of enforcing business rules at the database level for consistency and reliability. It also gave me hands-on experience with structured error handling and how collaborative projects maintain best practices for readable, tested, and maintainable code.
Reflections
This week was all about learning in depth rather than speed. I realized that not every pull request is about adding new features—sometimes it’s about understanding how different parts of a system connect and making sure a fix doesn’t cause new issues elsewhere. Community feedback also played a huge role; it’s not just about getting code merged but about improving through discussions and learning from experienced developers. As I wait for feedback from both Cloudinary and OpsiMate maintainers and finish my Hacktoverfest journey, I'm exploring other projects that excites me. Hacktoberfest has been a truly rewarding experience, helping me grow both technically and collaboratively.
Thank you for following my journey!
Top comments (0)