Improve HTTP Poller source log output

[jmcx]

The HTTP Poller source doesn't produce any logs when it is failing to get a response from its target HTTP service.

I can reproduce this by making a local server available, e.g.:

python3 -m http.server 8000

Then creating an HTTP Poller source that hits this server (replace the host.docker.internal hostname by whatever works on your env, possibly localhost):

tmctl create source httppoller --name ordersorderjson-httppollersource --method GET --endpoint http://host.docker.internal:8000 --interval 10s --eventType io.triggermesh.httppoller.event

I see events every 10s in tmctl watch.

Now if I stop the python HTTP server, I stop getting events, but HTTP poller doesn't show any logs.

[odacremolbap]

The adapter seems to work as expected.

If the polling endpoint is down a log entry is written for each poll iteration:

{"severity":"ERROR","timestamp":"2023-01-30T10:32:14.106041264+01:00","logger":"httppoller","caller":"httppollersource/httppoller.go:80","message":"Failed sending request","error":"Get \"http://localhost:8000\": dial tcp 127.0.0.1:8000: connect: connection refused","stacktrace":"github.com/triggermesh/triggermesh/pkg/sources/adapter/httppollersource.(*httpPoller).dispatch\n\t/home/pablo/go/src/github.com/triggermesh/triggermesh/pkg/sources/adapter/httppollersource/httppoller.go:80\ngithub.com/triggermesh/triggermesh/pkg/sources/adapter/httppollersource.(*httpPoller).Start\n\t/home/pablo/go/src/github.com/triggermesh/triggermesh/pkg/sources/adapter/httppollersource/httppoller.go:70\nknative.dev/eventing/pkg/adapter/v2.MainWithInformers\n\t/home/pablo/go/pkg/mod/knative.dev/eventing@v0.31.1-0.20220523181303-c3e13967001f/pkg/adapter/v2/main.go:257\nknative.dev/eventing/pkg/adapter/v2.MainWithEnv\n\t/home/pablo/go/pkg/mod/knative.dev/eventing@v0.31.1-0.20220523181303-c3e13967001f/pkg/adapter/v2/main.go:157\nknative.dev/eventing/pkg/adapter/v2.MainWithContext\n\t/home/pablo/go/pkg/mod/knative.dev/eventing@v0.31.1-0.20220523181303-c3e13967001f/pkg/adapter/v2/main.go:132\nknative.dev/eventing/pkg/adapter/v2.Main\n\t/home/pablo/go/pkg/mod/knative.dev/eventing@v0.31.1-0.20220523181303-c3e13967001f/pkg/adapter/v2/main.go:128\nmain.main\n\t/home/pablo/go/src/github.com/triggermesh/triggermesh/cmd/httppollersource-adapter/main.go:26\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:250"}

If the sink is down a log line is written for each lost event:

{"severity":"ERROR","timestamp":"2023-01-30T10:35:33.65042755+01:00","logger":"httppoller","caller":"httppollersource/httppoller.go:109","message":"Could not send Cloud Event","error":"Post \"http://localhost:9000\": dial tcp 127.0.0.1:9000: connect: connection refused","stacktrace":"github.com/triggermesh/triggermesh/pkg/sources/adapter/httppollersource.(*httpPoller).dispatch\n\t/home/pablo/go/src/github.com/triggermesh/triggermesh/pkg/sources/adapter/httppollersource/httppoller.go:109\ngithub.com/triggermesh/triggermesh/pkg/sources/adapter/httppollersource.(*httpPoller).Start\n\t/home/pablo/go/src/github.com/triggermesh/triggermesh/pkg/sources/adapter/httppollersource/httppoller.go:70\nknative.dev/eventing/pkg/adapter/v2.MainWithInformers\n\t/home/pablo/go/pkg/mod/knative.dev/eventing@v0.31.1-0.20220523181303-c3e13967001f/pkg/adapter/v2/main.go:257\nknative.dev/eventing/pkg/adapter/v2.MainWithEnv\n\t/home/pablo/go/pkg/mod/knative.dev/eventing@v0.31.1-0.20220523181303-c3e13967001f/pkg/adapter/v2/main.go:157\nknative.dev/eventing/pkg/adapter/v2.MainWithContext\n\t/home/pablo/go/pkg/mod/knative.dev/eventing@v0.31.1-0.20220523181303-c3e13967001f/pkg/adapter/v2/main.go:132\nknative.dev/eventing/pkg/adapter/v2.Main\n\t/home/pablo/go/pkg/mod/knative.dev/eventing@v0.31.1-0.20220523181303-c3e13967001f/pkg/adapter/v2/main.go:128\nmain.main\n\t/home/pablo/go/src/github.com/triggermesh/triggermesh/cmd/httppollersource-adapter/main.go:26\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:250"}

[tzununbekov]

I think that you folks are on different pages - @jmcx tmctl watch shows the events passing through the broker, while error messages provided by @odacremolbap are the adapter's log entries and they are not available in the watch output. One way to get them is tmctl logs -f, not sure if it fits the test scenario though. Did you mean that the source should send these errors as the events, @jmcx ?

[jmcx]

@tzununbekov I'm talking about log output, not in tmctl.

@odacremolbap I'll do a little video of the bug.

[sebgoa]

@jmcx is this still valid ?

[jmcx]

@jmcx to video the issue

[jmcx]

This was the original video I made: https://www.loom.com/share/84be1453844f4b70b78a1ea168836cf4.

Maybe there is some subtlety in there, but the fact that there are no error logs, and that it doesn't start working again after restarting the HTTP service, seems to indicate an issue somewhere...