https://github.com/stitchfix/hamilton logo
Join Slack
Powered by
This message was deleted.
# hamilton-help
s
This message was deleted.
e
It’s not customizable — feel free to open a ticket? Happy to discuss more, might be easy to configure with an env variable. We changed it recently to add more information— would be curious what you like/dont. In the meanwhile if you want a workaround, you could catch exceptions, match a quick regex, then just look for the node name and print that, although that’s a bit hacky…
m
ok, thanks
my immediate issue is that I sometimes have a long list passed as argument to a node, and when it fails, it prints it all out.
this is a service and the failure can be caused by connection issues, so if that happens, I am flooded with logs
so I'm trying to mitigate this
there's nothing in particular in the message itself that I like or dislike
I just ran out of log space this morning and this was the cause 😂
(I just disabled these logs altogether for the time being as workaround)
e
Ha fair! That makes sense — I think we can add a truncation (disclaimer I haven’t looked into what it does do for a bit so it’s possible it already does something), it can easily clobber the buffer of someone’s terminal and make debugging painful.
m
I'll see if I can find some time to dig deeper this week. rn I need to ship some workaround so I haven't had the time to look at the code more carefully.
e
So I think we can either truncate to some number of characters (1000?). Or add a variable DISABLE_DEBUG_ON_FAILURE
m
I think we probably don't want to always truncate, I'm sure in many cases it makes sense to show the entire message, even outside of debugging
tbh I would like to capture these somehow but in my particular trade-off it makes sense to not do that
we could add 
TRUNCATE_ERROR_MSG_LENGTH
(we can probably come up with a better name) to set no. chars to show, and if not defined, just print all. would that make sense?
e
Yeah I think that makes sense — this is also a fairly comon problem (error buffer overflows)
Should be a one-two line change, happy to sneak something likethat in today (will discuss with @Stefan Krawczyk first)
👍 1
Hey @Michal Siedlaczek — sorry I didn’t get a chance to get to this today. @Stefan Krawczyk and I will take a look tomorrow — should be easy we were just a bit slammed today
s
I was thinking something like this — the point of including it is to help someone make a quicker assessment of what the function is and what went into it - and so I don’t think anyone would want to overly rely on this to show everything input…
Copy code
inputs = {}
for k, v in kwargs.items():
    item_repr = repr(v)
    if len(item_repr) > 50:
        item_repr = item_repr[:50] + "..."
    else:
        item_repr = v
    inputs[k] = item_repr
input_string = pp.pformat(inputs)
if len(input_string) > 500:
    input_string = input_string[:500] + "..."
basically if you have a big item — only show the first 50 chars of it. Then another layer to catch the overall length and truncate it.
We can always tweak this number since I don’t think this is an API contract.
m
@Elijah Ben Izzy no worries, this not that urgent to me, I patched my project with silencing hamilton logs for now, that's good enough. it would be good to get some shorter info, but I'll get by for the time being 🙂
e
👍 great! Yeah still a quick fix though
@Michal Siedlaczek we decided on @Stefan Krawczyk’s idea, we’ll get it out with next week’s release (
1.48.0
)
m
👍 great, thanks for letting me know!
Open in Slack
PreviousNext
Powered by