An Empty Screen Is Not Always a Failure

Many users encounter an empty screen when expecting to see markup. The service responsible for this issue is the rule-set-markup service, which is the last link before the screen. At first glance, blaming this single service seems reasonable, as it is the final point of contact for the user. However, upon closer inspection, it becomes clear that this conclusion is not accurate.

Initially, the analysis involved running every object in the vertical through the endpoint and counting the responses. Roughly two-thirds of the objects returned a "not found" error, while others failed due to timing issues. This analysis led to the conclusion that 23 objects did not rebuild, falsely attributing the problem to the rule-set-markup service.

Upon further investigation, a more detailed analysis was conducted. Each object was questioned about its input and output. It was found that every object with input also had an output. Additionally, a comparison between the service's output and production data showed that 1,752 entities produced the expected results, with no discrepancies.

The empty screens are a real issue, but the service blamed for them is not the root cause. Instead, the problem originates from six different causes, each belonging to a different owner. These include the configuration's schedule, lack of keyword queries, missing schedule activation, queued tasks waiting for collection, providers not covering certain regions, and timing failures caused by the pace of the analysis itself.

The breakdown of the problem shifts the focus from blaming a single service to identifying specific owners for each empty screen. This breakdown allows for a more targeted approach to resolving the issue, as each cause can be addressed by the designated owner. The cost of this breakdown was the time and effort required to conduct the detailed analysis, but it ultimately leads to a more effective and efficient resolution.