Hi Noah,

On Thu, 2021-07-29 at 16:29 -0400, Noah Sanci wrote:
> Why have MAXTIME default to LONG_MAX? Which is long, but different
> > on
> > different arches 32/64bit. If MAXSIZE == 0 means infinite, why not make
> >  MAXTIME=0 the same for consistency?
> 
> Fixed.
> 
> > The bug suggests to also check the Content-Length header on reciept (in
> > case the server didn't support or respect the X-DEBUGINFOD-MAXSIZE
> > header. Did you try to implement that?
> 
> Fixed.
> 
> > I believe various error handling goto out1 should be goto out2 (after
> > your duplicate urls patch). Could you double check that?
> 
> Fixed.
> 
> > diff --git a/tests/run-debuginfod-find.sh b/tests/run-debuginfod-find.sh
> > index feec5ddf..8ed7743d 100755
> > --- a/tests/run-debuginfod-find.sh
> > +++ b/tests/run-debuginfod-find.sh
> > @@ -187,7 +187,7 @@ tempfiles find-vlog$PORT1
> >  # wait for the server to fail the same number of times the query is 
> > retried.
> >  wait_ready $PORT1 
> > 'http_responses_after_you_milliseconds_count{code="406"}' 1
> >  # quickly ensure all reporting is functional
> > -grep 'serving file '${PWD}'/F/p+r%o\$g.debug' vlog$PORT1
> > +grep 'serving file '$(realpath ${PWD})'/F/p+r%o\$g.debug' vlog$PORT1
> >  grep 'File too large' vlog$PORT1
> >  grep 'using max size 1B' find-vlog$PORT1
> >  if [ -f ${DEBUGINFOD_CACHE_PATH}/${BUILDID} ]; then
> 
> Fixed.

Great. Thanks. Although you don't just have to do things the way I like
them. Feel free to push back and tell me you feel the solution you
chose is better than what I am suggesting. It really is a conversation.

> Find all the fixes in the attached patch.

Looks like you attached the wrong patch (url-duplicate)

Cheers,

Mark

Reply via email to