While building a Spring Boot project recently, I ran into a bug that looked simple at first but turned out to be a classic backend trap. I had created an API to return account details. The database was fine, the relationships were mapped correctly, and the service logic was clean. But when I hit the endpoint, the API kept failing with a serialization error. After spending some time debugging, I realized the issue wasn’t in my business logic at all. It was happening when Spring Boot was converting my entities into JSON. Here’s what was going wrong: My entities had a bidirectional relationship. An Account had a reference to a Customer. The Customer had a list of Accounts. When the API tried to return an Account, Jackson started converting it to JSON. It saw the Customer inside the Account, so it tried to convert the Customer. Then it saw the list of Accounts inside the Customer, so it tried to convert those Accounts again. And this kept repeating. Account → Customer → Accounts → Customer → Accounts… This created an infinite loop, and eventually the application crashed. The tricky part was that nothing looked wrong in the code. The mappings were correct. The data was correct. But the serialization process didn’t know when to stop. Once I understood the root cause, the fix was straightforward. I used @JsonIgnore on the parent reference inside the child entities: i. Ignored Customer inside Account ii. Ignored Account inside Transaction and Loan By doing this, I told Jackson to stop traversing back up the relationship. After applying this change, the API returned a clean and finite JSON response, and everything worked as expected. This experience taught me an important lesson: In backend development, defining relationships is only half the job. You also need to control how those relationships are exposed in your API responses. #SpringBoot #Java #BackendDevelopment #SoftwareDevelopment #JPA #Hibernate #RESTAPI #Microservices #BackendEngineer #Debugging #TechLearning #Developers #CleanCode
SHUBHANSHU KUMAR
1mo
Yes, your account called toString of Customer and vice versa and it kept happening and reached the recursion depth. You can exclude it from toString or use Json ignore or even better if you set the return info in some DTO
Classic trap that everyone hits at least once. Instead of JsonIgnore which completely hides the field, try JsonManagedReference on the parent side and JsonBackReference on the child side. That way the relationship is still visible from one direction but avoids the infinite loop. Another approach we follow is to never expose entities directly in API responses at all and use DTOs instead. That way you have full control over what gets serialized and you dont accidentally leak lazy-loaded proxy objects. MapStruct makes the entity-to-DTO mapping painless and the separation pays off massively as the project grows.