# Contributor Journey — Learnings, Blockers & Questions from My First PRs \[GSoC 2026\] **URL:** \ **Category:** Development\ **Tags:** dev, gsoc2026\ **Created:** [March 28, 2026, 9:51am UTC](https://talk.openelis-global.org/t/contributor-journey-learnings-blockers-questions-from-my-first-prs-gsoc-2026/2226 "2026-03-28T09:51:43Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Rakesh](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/rakesh/32/1213_2.png) [@Rakesh](https://talk.openelis-global.org/u/Rakesh)\ **Post date:** [March 28, 2026, 9:51am UTC](https://talk.openelis-global.org/t/contributor-journey-learnings-blockers-questions-from-my-first-prs-gsoc-2026/2226/1 "2026-03-28T09:51:43Z")
Hi OpenELIS Community! 👋 I’m Rakesh Honawad, a GSoC 2026 applicant actively contributing to OpenELIS Global 2. Over the past 3 weeks I’ve submitted several PRs focused on improving unit and integration test coverage across multiple service classes. I wanted to share my learnings, blockers I hit, and ask some questions that came up during the process. * * * ## 🔧 My Active PRs | PR | Service | Description | | --- | --- | --- | | #3208 | InventoryItemService | 10 new integration tests | | #3194 | AnalysisService | 6 improved test cases | | #3077 | PanelService | Additional integration tests | | #3037 | RegionService | 4 new test cases | | #3027 | AnalysisService | Additional unit tests | | #3023 | AnalysisService | Unit tests for getAnalysisType, getStatusId, getTriggeredReflex | Total: 25+ new unit and integration tests added across 4 service classes in 3 weeks. * * * ## ✅ What I Learned **1. Always run mvn spotless:apply before committing** I learned this the hard way when @mozzy11 flagged formatting issues on PR #3023. Now it’s the first thing I do before every commit. **2. assertNotNull on a primitive boolean is meaningless** On PR #3194, Copilot review caught that assertNotNull on a boolean always passes due to autoboxing. Should use assertTrue/assertFalse with known fixture data instead. **3. BaseDAOImpl.get() returns null for missing IDs** I initially wrote a test expecting ObjectNotFoundException for invalid IDs, but the base DAO simply returns null. Important to understand base class behaviour before writing tests. **4.** @After **tearDown pattern requires setLastupdated()** In RegionServiceTest, the tearDown calls deleteAll() which requires lastupdated to be set on each entity first. Missing this caused issues with test cleanup. **5. Rebase pulls in workflow files requiring PAT workflow scope** After rebasing on develop, pushing was rejected because workflow files were picked up. Fix is to add workflow scope to your GitHub Personal Access Token settings at [Sign in to GitHub · GitHub](https://github.com/settings/tokens) **6. Hard-coded IDs like get(“1”) are brittle** Copilot review on #3194 pointed out that hard-coded primary keys break if dataset changes. Better to use existing fixture helpers like createDemoAnalysis() or select by stable attributes. * * * ## ❓ Questions for the Community **Q1: E2E failures unrelated to code changes** On multiple PRs (#3037, #3077, #3194, #3208) the E2E pipeline fails with: “Unable to download artifact: e2e-image-map-base” “Unable to download artifact: e2e-plugin-jars” My PRs only modify test files with zero production code changes. Backend ✅ and Frontend ✅ pass successfully on all of them. Is there a way for contributors to distinguish infrastructure CI failures from code-related ones? A label or wiki note would really help new contributors not panic! **Q2: Known bug in InventoryItemDAOImpl.getByItemType()** While writing tests for InventoryItemService (PR #3208) I found that getByItemType() throws: “ERROR: operator does not exist: character varying = bytea” This appears to be a PostgreSQL type mismatch bug in the production DAO code. I marked the affected tests as @Ignore with a clear note explaining the bug. Should I open a separate GitHub issue for this? Happy to investigate further if it would help. **Q3: Preferred test isolation pattern** For destructive tests like deleteAll(), is @Transactional rollback preferred over @After cleanup in this codebase? I noticed existing tests use @After tearDown() pattern — just want to follow the established convention. **Q4: Multiple PRs for same service** I noticed I have 3 PRs open for AnalysisService (#3023, #3027, #3194). #3194 contains the most improved version based on Copilot feedback. Should I close the older ones and consolidate into #3194? I want to keep things clean for reviewers. * * * ## 🙏 Request for Review Would love a review on the following PRs which have been open for 2-3 weeks: - #3037 RegionService — rebased and spotless applied ✅ - #3077 PanelService — backend and frontend passing ✅ - #3023 AnalysisService — rebased and spotless applied ✅ Happy to make any changes based on feedback! * * * Looking forward to contributing more to OpenELIS. I’m very excited about the GSoC 2026 project ideas and would love to discuss how I can contribute further during the program! 🚀 — Rakesh Honawad GSoC 2026 Applicant GitHub: [Rakesh-honawad (Rakesh Honawad) · GitHub](https://github.com/Rakesh-honawad) cc: @herbertyiga @mozzy11 @pmanko