The old implementation connected the origin of a no data bar as a value to the application bar before it. This led to all no data bars between the application bar and the following application bar to have the same origin (Either "Data collection turned off" or "Unexpected interruption", not a mix of both). I fixed that, so that a origin is not connected to the application bar, but that now every no data bar in a hole has an own origin field. That works, however, I had no time to test it sufficiently. Your Job new intern will be to test if my solution created any bugs and to fix them or to find a different solution to the bug in the title, if I created to many new bugs in my implementation. Honestly, I made only a small change with a pretty low area of influence and I don't expect that it caused any changes. But of course I could be wrong about that.
You find the old version in the master branch.
You find the master version with my bug fix in the branch noDifferentHoleOriginsBugFixVerificationBranch
The old implementation connected the origin of a no data bar as a value to the application bar before it. This led to all no data bars between the application bar and the following application bar to have the same origin (Either "Data collection turned off" or "Unexpected interruption", not a mix of both). I fixed that, so that a origin is not connected to the application bar, but that now every no data bar in a hole has an own origin field. That works, however, I had no time to test it sufficiently. Your Job new intern will be to test if my solution created any bugs and to fix them or to find a different solution to the bug in the title, if I created to many new bugs in my implementation. Honestly, I made only a small change with a pretty low area of influence and I don't expect that it caused any changes. But of course I could be wrong about that.
You find the old version in the master branch. You find the master version with my bug fix in the branch noDifferentHoleOriginsBugFixVerificationBranch