Show blocked requests correctly

[DBX12]

Is your feature request related to a problem? Please describe. When a request is blocked for some reason, the response is rendered with status code zero. Reading the field response._error might help in finding out why the request was blocked.

Describe the solution you'd like Maybe show a note on the connection with the contents of response._error (for example net::ERR_BLOCKED_BY_CLIENT)

Describe alternatives you've considered Maybe rework the colors used for highlighting the initiator so red can be used for blocked requests. In any case, the return from the request must not be shown.

Additional context Example request (truncated for brevity):

{
  "_initiator": {...},
  "_priority": "Low",
  "_resourceType": "image",
  "cache": {},
  "pageref": "page_1",
  "request": {...},
  "response": {
    "status": 0,
    "statusText": "",
    "httpVersion": "",
    "headers": [],
    "cookies": [],
    "content": {
      "size": 0,
      "mimeType": "x-unknown"
    },
    "redirectURL": "",
    "headersSize": -1,
    "bodySize": -1,
    "_transferSize": 0,
    "_error": "net::ERR_BLOCKED_BY_CLIENT"
  },
  "serverIPAddress": "",
  "startedDateTime": "2022-10-28T16:29:31.302Z",
  "time": 6.7949999998973,
  "timings": {
    "blocked": 6.7949999998973,
    "dns": -1,
    "ssl": -1,
    "connect": -1,
    "send": 0,
    "wait": 0,
    "receive": 0,
    "_blocked_queueing": -1
  }
}

[DBX12]

And I might want to work on that, if you agree that showing blocked requests in that way is sensible :)

[dnnrly]

Yes, I think this is a good idea. Might be worth exploring the Puml docs to see if there's something that can represent that connection termination properly. I think there's a bold cross in there somewhere.

[DBX12]

Indeed, you can specify a connection as Bob ->x Alice and it shows the message being terminated before it reaches Alice. I guess that is the way to go, even better than using colors (again). Edit: What is your take on the details of the termination? Should we show it always in a note or have it hidden behind another command line flag? There shouldn't be so many terminated requests so it wouldn't be cluttering the diagram as much as the verbose initiator information does.

[dnnrly]

Keep the ideas coming, it's easier to triage them than get new ones.

As for your suggestion, maybe worth looking in to having a flag to show the entire legend or not. Might be simpler than having logic to figure it out what it looks like. And you could make the legend a bunch of static text then.

[DBX12]

I'm working on it and realizing, the Har.Draw() method gets more and more complex. What do you think on going a more object-oriented approach and moving some logic into the Entry struct? For example, the InitiatorTypeToColor() could be a method on the Entry struct, as well as a new IsRequestBlocked() method or a method to decide which tip the connector should have. But I would also understand if you want to keep the business logic out of the properties of Har.

[dnnrly]

I'd prefer to keep that business logic out. But you're right, it does feel like it's all a bit messy. Perhaps have every component decide whether or not it needs to be drawn?

[dnnrly]

I mean, try raising a draft PR to see how the code looks. It might be that you come up with a suitable solution. And it's easier to look at it in code.