podman events --since="nonsense" is nondeterministic

[edsantiago]

It will sometimes succeed!

$ t0=$SECONDS;i=0;while :;do i=$((i+1));bin/podman events --since="the dawn of time...ish" && break;done;printf "%d seconds, %d tries\n" $((SECONDS-$t0)) $i
...
Error: failed to parse event filters: unable to convert since time of the dawn of time...ish: unable to interpret time value
74 seconds, 3674 tries

And sometimes that will continue looping forever (or five minutes, which is ~equivalent). I have no idea what makes it "succeed". And, given a loop exit, no idea what to do to investigate.

[edsantiago]

A few more failures:

1361 seconds, 67355 tries
...
602 seconds, 29632 tries  (using --since=nonsense)

Still no idea what triggers this.

[edsantiago]

Very weird. I thought the problem might be

podman/pkg/util/utils.go

Lines 1112 to 1141 in c279ce0

	// ParseInputTime takes the users input and to determine if it is valid and
	// returns a time format and error. The input is compared to known time formats
	// or a duration which implies no-duration
	func ParseInputTime(inputTime string, since bool) (time.Time, error) {
	timeFormats := []string{time.RFC3339Nano, time.RFC3339, "2006-01-02T15:04:05", "2006-01-02T15:04:05.999999999",
	"2006-01-02Z07:00", "2006-01-02"}
	// iterate the supported time formats
	for _, tf := range timeFormats {
	t, err := time.Parse(tf, inputTime)
	if err == nil {
	return t, nil
	}
	}
	unixTimestamp, err := strconv.ParseFloat(inputTime, 64)
	if err == nil {
	iPart, fPart := math.Modf(unixTimestamp)
	return time.Unix(int64(iPart), int64(fPart*1_000_000_000)).UTC(), nil
	}
	// input might be a duration
	duration, err := time.ParseDuration(inputTime)
	if err != nil {
	return time.Time{}, errors.New("unable to interpret time value")
	}
	if since {
	return time.Now().Add(-duration), nil
	}
	return time.Now().Add(duration), nil
	}

returning a false non-error value somehow, so I instrumented it with logrus on every return... and nope, it's actually returning from line 1135, "unable to interpret". I can only conclude that whoever is calling filters.go:generateEventFilters() is not handling the error. And with that I'm outta here for the night.

[Luap99]

The issue is with how channels and select work I would assume, i.e. see c46884a

I guess that didn't really fix the main cause as the default: just skips the error if the channel does not yet contain the error.