Dev Log: September 01 Wrap-up

Overview

Had a bit of a mixed bag today. Spent a good chunk of time hunting down some edge-case bugs in our PDF reporting engine and cleaning up some session-handling logic in the frontend. It was one of those days where a few lines of code fixed issues that were causing major headaches for the end users.

What I Worked On

Fixing the Charting Crash

I ran into a classic ArrayIndexOutOfBoundsException in our charting service. We have a component that draws multi-line diagrams for patient growth charts (height, weight, etc.). It turns out the color palette was hardcoded to 11 colors.

Everything worked fine until someone tried to generate a report that combined multiple indicators, pushing the series count to 12. Since the rendering library we use doesn't have a global exception handler for the drawing phase, the entire PDF generation would just fail silently or throw a 500 error. I refactored the drawer to wrap the color index using a modulo operator so it just cycles back through the palette if we have an unusually high number of data series.

// Simple fix to prevent the palette from overflowing
int colorIndex = seriesCounter % COLOR_PALETTE.length;
apply_series_color(COLOR_PALETTE[colorIndex]);

While I was in there, I also fixed how we highlight specific patient data. It was only tracking a single string, meaning if a chart had multiple patient-related series, only the last one found would get highlighted. I switched that over to a Set to keep track of all relevant categories properly.

Reporting Engine: The Case of the Missing Banners

I spent some time on a tricky bug in the reporting engine regarding "cumulative prints." This happens when you try to print reports for a mix of In-patients (IP) and Out-patients (OP) at the same time.

The engine was essentially "freezing" the banner template based on the very first record it processed. If the first patient was an Out-patient, the banner keys for things like Ward Name or Bed Number didn't exist in that record's map. Consequently, even when the next page was for an In-patient, the engine wouldn't even look for those keys, leaving the fields blank. It’s a classic case of assuming the first data point defines the schema for the rest. I updated the logic to rebuild or check the keys dynamically per page so we don't lose that context.

Smoothing out the "Get Started" Flow

On the frontend, I had to fix a frustrating loop where users were getting hit with "Session access denied" errors. We have an anonymous landing page that uses a widget, and it was aggressively refreshing the authentication token on every single page load.

This was clobbering the session-scoped token that the widget actually needed to function, essentially kicking the user out of their own session before they even started. I tweaked the initialization logic to reuse a still-valid stored token if it exists. I also remapped some of our internal resource identifiers to ensure the anonymous flow hits the correct non-authenticated endpoints.

Wrapping Up

It feels good to clear out these kinds of bugs. They aren't always the most glamorous to work on, but they're the ones that make the product feel "broken" to a user when they hit them. Tomorrow, I'm hoping to dive back into some more feature-heavy work now that the reporting engine is behaving itself again.

Catch you later.