[Uptime] Waterfall view is squished

[andrewvc]

On my work laptop (ubuntu 20.04) the waterfall view text looks all squished, as below:

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[dominiqueclarke]

This bug occurs when there is an unequal amount of sidebar items versus the amount of data points for the x axis (or y axis, since the the chart is rotated 90 degrees). When the timings for an individual resource are not fetched successful, they are omitted from the data fed to Elastic Charts causing this disparity between the number of resources listed and the number of resources for which there are timings.

This bug was discovered when using the synthetics todos example, which attempts to fetch timings for static files within the file system. Failing more gracefully would be ideal, but after discussing with @andrewvc it was suggested that this bug be moved to lower priority, since this is an uncommon use case. Ideally, the todos example would also be adjusted to work seamlessly with waterfall chart development.

[paulb-elastic]

Do we have a view on if this is only really happening because we are loading resources from the local file system (which I agree, is a rare use case), or will this also happen (squashed view) whenever we don’t have timings for a resource, but have identified the URL of the request? This could potentially happen more often (I don’t think we have enough exposure or use cases yet to know for sure), in which case it will be more of an issue. /cc @vigneshshanmugam

IMHO I think it would be better to show the URL with no timing graph/bar if we don’t have metrics for it, as it will be clearer in the UI that we’ve identified the URL/request, but don’t have any timings for it (which in itself may lead to a bug being raised so that we can identify cases where we don’t get timings).

As an example, although it’s not exposing the above (squashed) issue, we have elastic/synthetics#175 raised where we don’t show redirect requests in the waterfall chart. There could be other cases where we do identify the URL but not the metrics, triggering the above issue.

[andrewvc]

@paulb-elastic that's a good question, in the todos case it's undoubtedly because of the use of a local file system. I have a feeling either @vigneshshanmugam or @jahtalab already know the answer here.

[vigneshshanmugam]

For the local file system, We wont be able to retrive the individual timing information(Blocked, DNS, TCP, etc.) for all events. However the agent already reports the total time (timings.total), so we can present the waterfall chart for the whole duration instead of leaving it out empty.

Output of the network event.

{
  "type": "journey/network_info",
  "@timestamp": 1609785637365580,
  "journey": {
    "name": "check that title is present",
    "id": "check that title is present"
  },
  "step": {
    "name": "go to app",
    "index": 1
  },
  "payload": {
    "step": {
      "name": "go to app",
      "index": 1
    },
    "timestamp": 1609785637365580,
    "url": "file:///Users/vigneshh/elastic/synthetic-monitoring/examples/todos/app/vue.min.js",
    "request": {
      "url": "file:///Users/vigneshh/elastic/synthetic-monitoring/examples/todos/app/vue.min.js",
      "method": "GET",
      "headers": {
        "referer": "",
        "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/88.0.4324.0 Safari/537.36"
      },
      "mixed_content_type": "none",
      "initial_priority": "High",
      "referrer_policy": "no-referrer-when-downgrade"
    },
    "type": "Script",
    "method": "GET",
    "request_sent_time": 949706.139291,
    "is_navigation_request": false,
    "status": 0,
    "load_end_time": 949706.141498,
    "response_received_time": 949706.140927,
    "response": {
      "url": "file:///Users/vigneshh/elastic/synthetic-monitoring/examples/todos/app/vue.min.js",
      "status": 0,
      "status_text": "",
      "headers": {},
      "mime_type": "text/javascript",
      "connection_reused": false,
      "connection_id": 0,
      "from_disk_cache": false,
      "from_service_worker": false,
      "from_prefetch_cache": false,
      "encoded_data_length": 93670,
      "protocol": "file",
      "security_state": "secure"
    },
    "timings": {
      "blocked": null,
      "queueing": -1,
      "proxy": -1,
      "dns": -1,
      "ssl": -1,
      "connect": -1,
      "send": -1,
      "wait": -1,
      "receive": -1,
      "total": 2.2070000413805246
    }
  },
  "package_version": "0.0.1-alpha.8"
}

[vigneshshanmugam]

Also, this bug needs to be prioritised as this could happen for all static resources that can be cached via service worker or similar caching mechanisms.