Verify that `service.name` is required for data to be sent

[beniwohli]

We got reports of data from the Python agent making it to the APM Server without service.name being set. service_name is a required configuration, and we set disable_send to True if it is missing, so there might be a bug somewhere there.

apm-agent-python/elasticapm/conf/__init__.py

Line 255 in 1d8f183

service_name = _ConfigValue("SERVICE_NAME", validators=[RegexValidator("^[a-zA-Z0-9 _-]+$")], required=True)

apm-agent-python/elasticapm/base.py

Lines 106 to 110 in 1d8f183

	config = Config(config, inline_dict=inline)
	if config.errors:
	for msg in config.errors.values():
	self.error_logger.error(msg)
	config.disable_send = True

cc @simitt

[basepi]

What constitutes lack of service.name? Was it completely absent from the payload?

As far as I can tell, if service.name isn't set, Beni is right, we don't send anything.

That said, I wonder if we could be seeing an interaction with an odd value here?

For example, our RegexValidator uses the regex "^[a-zA-Z0-9 _-]+$", which technically allows for a service name of " ", which could easily be stripped to an empty string (either by us or by the APM Server). Perhaps that fails validation on the APM server side or is dropped somewhere in the line?

Additionally, if a user set that config value to False or None, those would actually pass muster, because we convert to string in the validator. Perhaps these string values could be accidentally converted by either the APM server or by Elasticsearch and end up being null?

Those are the only two potential edge cases I can see, neither of which would be particularly easy to do accidentally. I haven't done any end to end testing yet, I've mostly just been following code paths.

@simitt Do either of those seem plausible or do I need to dig deeper? And who reported the initial issue? Can we get more information from that user?

[simitt]

@basepi service names consisting of only spaces are allowed and processed by APM Server, and the service would even show up in Kibana (with the name being blank). I don't think this would explain the issue. Strings such as "None" or "False" are processed as regular strings, also showing up in Kibana.

[basepi]

@beniwohli found the source of this issue, fixed in #927.