-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add ingress events to timeline #2735
Conversation
fd34982
to
11024ed
Compare
} | ||
observability.Ingress.Request(r.Context(), r.Method, r.URL.Path, optional.Some(verbRef), startTime, optional.Some(errMsg)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind changing the final optional.Some
back to sending a static string instead of err.Error()
? Otherwise the cardinality of the error field blows up and makes brad cry tears of money
Same for all the other observability calls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do! I was under the impression that attributes changing would not increase billing, but it sounds like that's not the case so thanks for catching this! I was mostly trying to avoid all the duplication here, but sounds that duplication is useful in this case.
I'll try to clean this up with some helper functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh that makes sense. Thanks thanks!
observability.Ingress.Request(r.Context(), r.Method, r.URL.Path, optional.Some(verbRef), startTime, optional.Some(err.Error())) | ||
ingressEvent.Response = &http.Response{StatusCode: http.StatusInternalServerError} | ||
ingressEvent.Error = optional.Some(err.Error()) | ||
timelineService.InsertHTTPIngress(r.Context(), &ingressEvent) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about making a helper func for these, since there's the duplication between here and below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So much duplication 😂 helpers to the rescue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The helper was gnarly to cover everything so I just made a helper for the new timeline error events. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sweet sgtm!
func callEventToCall(event *CallEvent) *Call { | ||
var response either.Either[*ftlv1.CallResponse, error] | ||
if eventErr, ok := event.Error.Get(); ok { | ||
err := errors.New(eventErr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this err
is only used on the line below, what do you think about inlining it as response = either.RightOf[*ftlv1.CallResponse](errors.New(eventErr))
?
Request json.RawMessage `json:"request"` | ||
RequestHeader json.RawMessage `json:"req_header"` | ||
Response json.RawMessage `json:"response"` | ||
ResponseHeader json.RawMessage `json:"res_header"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ultra nitty nit: I don't think I've seen response
abbreviated to res
- only to resp
. It is annoying that resp
is 4 long while req
is 3, so they don't match nicely then, but if I saw res_header
with no context, I probably wouldn't guess what it is. What do you think? No strong feelings on my part
Error optional.Option[string] `json:"error,omitempty"` | ||
} | ||
|
||
type Ingress struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wanna nest this in IngressEvent
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I very much do, but they are a bit too different. Like when creating an event I never want the requestKey to be missing, but it's allowed to be in the db. Similar to Request
and Response
where since they are different types it might get confusing to users of the API.
I had to do something similar with CallEvent
:(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahhhh got it, that makes sense
Request: []byte(`{}`), | ||
RequestHeader: []byte("{}"), | ||
Response: []byte(`{}`), | ||
ResponseHeader: []byte("{}"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two things:
- Should we add another test with more content in these fields to make sure all the json marshaling works correctly?
- I feel like I'm probably missing something but why do some of these have " and others have `?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- You bet!
- Nah, just copy/pasta errors :) Thanks for flagging!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was surprisingly hard to decipher the json marshalling 😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hehehe
<ul className='pt-4 space-y-2'> | ||
<li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually need all these to be wrapped in the <ul>
and <li>
elements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's consistent with the other detail pages for now, but yeah we should probably take a pass at these at some point. I'm not sure we even want to leave this current layout tbh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah that makes sense
{selectedIngress.response !== 'null' && ( | ||
<> | ||
<div className='text-sm pt-2'>Response</div> | ||
<CodeBlock code={JSON.stringify(JSON.parse(selectedIngress.response), null, 2)} language='json' /> | ||
</> | ||
)} | ||
|
||
{selectedIngress.requestHeader !== 'null' && ( | ||
<> | ||
<div className='text-sm pt-2'>Request Header</div> | ||
<CodeBlock code={JSON.stringify(JSON.parse(selectedIngress.requestHeader), null, 2)} language='json' /> | ||
</> | ||
)} | ||
|
||
{selectedIngress.responseHeader !== 'null' && ( | ||
<> | ||
<div className='text-sm pt-2'>Response Header</div> | ||
<CodeBlock code={JSON.stringify(JSON.parse(selectedIngress.responseHeader), null, 2)} language='json' /> | ||
</> | ||
)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since these are so similar, what do you think about adding a helper component that looks like:
const CodeBlockIfNotNull({ heading, maybeNullContent }) => {
if (maybeNullContent === 'null') {
return
}
return (
<>
<div className='text-sm pt-2'>{heading}</div>
<CodeBlock code={JSON.stringify(JSON.parse(maybeNullContent), null, 2)} language='json' />
</>
)
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same below for the attribute badges
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a helper for the code blocks that are just strings
but we'll want to rethink all of this with some better design so I don't want to spend too much effort on it just yet :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sweet sgtm!
11024ed
to
004f7d1
Compare
Fixes #2518
Successful ingress request
Failed ingress request