Per-sink acknowledgements don't override global option

[andrewma2]

Hi, I had recently raised a discussion involving acknowledgements. While I was tinkering around with ack's around that question, I noticed some odd behavior

With the toy config below, I would've expected to get an immediate response back from a curl request to the source endpoint. This is since in has one sink, where I've explicitly disabled ack's. And even though it's enabled globally, per the documentation:

Enabling or disabling acknowledgements at the sink level takes precedence over any global acknowledgements configuration.

However, I do see that my request hangs for 10s and only responds once the batch timeout hits and vector attempts to send out from the sink*. Similarly, if I flip it so globally ack's are off and the per-sink ack is on, I get an instant response when I would expect it to wait until vector attempts a send. This is on vector v0.45, is this expected behavior?

Thanks!

*Note: The sink send will fail with the config on its own as there's no downstream receiver, but I don't think that changes the specific behavior I'm investigating

{
	"acknowledgements": {
		"enabled": true
	},
	"sources": {
                "in": {
                        "type": "http_server",
                        "address": "0.0.0.0:80"
                }
        },
	"sinks": {
		"out": {
			"acknowledgements": {
				"enabled": false
			},
			"type": "http",
			"inputs": ["in"],
			"uri": "0.0.0.0:10",
			"encoding": {
				"codec": "json"
			},
			"batch": {
				"timeout_secs": 10,
				"max_events": 1000
			},
			"request": {
				"retry_attempts": 1
			},
			"buffer": {
				"max_events": 100
			}
		}
	}
}

I'm hitting the source endpoint with curl 0.0.0.0:80 -X POST -d '{}'

[pront]

Hi @andrewma2, apologies for the late response. I tried your setup locally with a dummy server that accepts everything that the http sink publishes to it. curl 0.0.0.0:80 -X POST -d '{}' returns immediately.

Did you confirm that the downstream server returned 200?