When crafting a payload to test Loki it was discovered that a json push request could be structured such that Loki can correctly parse the json but extracts no labels nor logs from it.
There exist validations to make sure a push request has valid labels (a push request cannot have zero labels), however, prior to reaching that code there are several places we exit early if there are no streams or entries found, and we exit with the 204 status code which indicates a successful push.
I don't think a 204 "no content" response which is also used to indicate success should be returned here, rather a 400 Bad Request feels like the least surprising thing to consumers of the API who could then get a message indicating why their logs are not being displayed when they query.
Describe the bug
When crafting a payload to test Loki it was discovered that a json push request could be structured such that Loki can correctly parse the json but extracts no labels nor logs from it.
There exist validations to make sure a push request has valid labels (a push request cannot have zero labels), however, prior to reaching that code there are several places we exit early if there are no streams or entries found, and we exit with the 204 status code which indicates a successful push.
https://github.com/grafana/loki/blob/9f31b25253502f035cfb6a831bcea7f778f427dd/pkg/distributor/distributor.go#L343-L345
https://github.com/grafana/loki/blob/9f31b25253502f035cfb6a831bcea7f778f427dd/pkg/distributor/distributor.go#L460-L462
to exit early at the first point the json just needs to be valid and NOT contain a
streamskeyto exit at the second point, the json needs to be valid and contains a
streamskey:Expected behavior
I don't think a 204 "no content" response which is also used to indicate success should be returned here, rather a 400 Bad Request feels like the least surprising thing to consumers of the API who could then get a message indicating why their logs are not being displayed when they query.