Repowise flagged our Razorpay webhook handler as the single highest-risk function in the codebase - and it was the right call

[RuchaChavan21]

Executed repowise init and repowise health on DivineSpark, a Spring Boot booking application I developed (JWT authentication, Razorpay payments, over 1K concurrent users). 167 documents, 209 updates, no LLM requests for the scan.

Of the 197 marker findings, just one was marked as high / function_hotspot with the lowest impact score in the whole report (-1.39): handleWebhook in PaymentWebhookController.

This function handles the incoming Razorpay payment webhooks and it's truly the most critical code in the application, as it is the sole location where external, unverified input directly influences payment status changes. Examining it reveals the clear reason: it contains nested conditionals that depend on various payment statuses (created, authorized, captured, failed, refunded), representing a control flow that's simple to inadvertently mismanage and difficult to thoroughly test mismanaging one branch could lead to a payment incorrectly marked as captured or a webhook retry that processes a transaction twice.

What led me to trust the score: Repowise validated itself against my git history 45% of the 20 files with the lowest health had a bug fix in the past 6 months, compared to an 8% baseline for the entire repository. 5.78x increase, relying solely on the dependency graph and commit history.

A secondary observation I might have missed: six Admin*Controller classes (Blog, Event, Program, Review, Session, Thumbnail) along with AuthController were each identified as having low cohesion. Each appears fine on its own the pattern only emerges when you view all seven marked similarly at the same time.

Extracting the state transition logic into its own tested unit by refactoring handleWebhook is my next task.