-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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: extend component run info #8436
Conversation
Are inputs and outputs lengths really necessary? Which use case would stop people from calculating it themselves? 🤔 |
@silvanocerza Not sure what you mean with "calculating it themselves" exactly.
To actually monitor progress and to decide whether an invocation takes too long or is within bounds you need to know input and output lengths of the individual components. OCR might be quick for 5 pages, but take an hour for 1k pages. |
Pull Request Test Coverage Report for Build 11178179903Details
💛 - Coveralls |
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'm afraid this change falls outside the purview of the the Pipeline
class. The current tracing hooks expose the inputs of each component run invocation, and that's the extent of the class' involvement - It's up to the consumer of the tracing instrumentation to house the logic that reasons about those inputs.
We can additionally log the parameters that we currently passing to the tracing instrumentation (and add the output types to that), but logic to infer lengths doesn't belong here.
@shadeMe So how would I log the number of input and output items (which I believe is an important number for debugging/monitoring pipelines)? |
Not sure what your constraints are, but perhaps by creating a custom tracer that inspects the inputs and output and writes their characteristics to to the logs? The On second thought, such a tracer would be a useful tool for Haystack users too. |
@shadeMe If the LoggingTracer is the way to go, do you think adding the extra to the existing log lines in this PR makes still sense? |
I don't see an issue with logging the input and output types, if only for completeness' sake. |
|
Related Issues
Background:
Currently there is little to no information about a component's run invocation in our logs. We get a log
Running component writer
without any further information. Additional information is only available via tracing. Traces are not always available or suitable in certain situations as for example user-facing logs.Proposed Changes:
How did you test it?
Notes for the reviewer
Checklist
fix:
,feat:
,build:
,chore:
,ci:
,docs:
,style:
,refactor:
,perf:
,test:
.