Evidence Page - Unexpected Application Error

Update timeline

1. investigating May 26, 2026, 08:28 PM UTC

   Users may experience an unexpected error when accessing the Evidence page. The application fails to load due to a null reference issue while processing evidence data. Our team is investigating and working on a fix.

2. identified May 26, 2026, 08:59 PM UTC

   The issue has been identified and a fix is being implemented.

3. monitoring May 26, 2026, 09:17 PM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved May 26, 2026, 09:26 PM UTC

   The issue causing the Evidence page to crash has been identified and resolved. The page is now loading correctly for all users. We apologize for the disruption and appreciate your patience while we worked through it.

5. postmortem May 30, 2026, 05:45 AM UTC

   ## Impact All users on the platform experienced the inability to view or upload evidence on finding pages for approximately 58 minutes. Both the web interface and the desktop application were affected. Users without access to certain findings were additionally stuck in a reload loop during the same window. The issue started on UTC-5 26-05-26 14:35 and was proactively discovered 57.6 minutes \(TTD\) later by a staff member who noticed that evidence data was not loading and alerted the team. The problem was resolved in 57.6 minutes \(TTF\), resulting in a total window of exposure of 1.9 hours \(WOE\). ## Cause A planned dependency upgrade deployed to remediate reported security vulnerabilities introduced an undocumented behavioral change in a core library responsible for mapping GraphQL field names to their internal data keys. Under the previous version, fields whose names were entirely lowercase were left unchanged during this mapping. Under the upgraded version, all fields, regardless of casing were passed through a name converter that inserts underscores before numeric characters. As a result, fields such as those used to store evidence items were silently redirected to keys that did not exist in the underlying data, causing them to return empty values instead of their content. The behavioral change was documented in the library's internal pull request history but was not prominently surfaced in the official changelog, and the existing test suite did not cover the full name-resolution flow against a live schema. ## Solution An emergency rollback to the previous dependency versions was deployed the same day, restoring all affected functionality within the incident window. A definitive fix was subsequently developed and deployed two days later: the dependency upgrade was re-applied alongside a custom name-mapping configuration that preserves the correct resolution behavior for all-lowercase field names while still applying the standard conversion to mixed-case names. Automated tests were added to explicitly validate that all numbered evidence fields resolve to their expected values, preventing silent regressions of this class in future dependency upgrades. ## Conclusion Major-version upgrades to core GraphQL infrastructure libraries must be accompanied by integration tests that exercise the full field-name resolution pipeline against a real executable schema not only unit tests of business logic. The failure was silent by design: fields returned empty values without raising errors, making it indistinguishable from missing data until users reported it. Future upgrades to schema-handling libraries require an explicit end-to-end assertion that no field resolves to null when data is present. **THIRD\_PARTY\_CHANGE < MISSING\_TEST < INCOMPLETE\_PERSPECTIVE**