Don't log BuildEnvironmentWarning as error

[stsewd]

Turns out we are logging this manually

readthedocs.org/readthedocs/projects/tasks.py

Lines 254 to 265 in 00ab116

	except Exception:
	# Catch unhandled errors when syncing
	log.exception(
	'An unhandled exception was raised during VCS syncing',
	extra={
	'stack': True,
	'tags': {
	'project': self.project.slug,
	'version': self.version.slug,
	},
	},
	)

Closes #4590

[humitos]

It is supposed that we are not logging BuildEnvironmentWarning already (

readthedocs.org/readthedocs/projects/tasks.py

Line 286 in 70ca7c7

BuildEnvironmentWarning,

). I'm not sure to follow why catching this exception and re-raising it as RepositoyError will avoid the log in Sentry.

I feel confused here 😕

[stsewd]

Yes, but that isn't the cause. We are logging it manually here

readthedocs.org/readthedocs/projects/tasks.py

Lines 254 to 265 in 00ab116

	except Exception:
	# Catch unhandled errors when syncing
	log.exception(
	'An unhandled exception was raised during VCS syncing',
	extra={
	'stack': True,
	'tags': {
	'project': self.project.slug,
	'version': self.version.slug,
	},
	},
	)

That try...except block only captures RepositoryError and LockTimeout, everything else is logged

[humitos]

Gotcha! Do you know why the sync_repo is not ran inside the context manager that manages all the exceptions in the __exit__ as we do run all the rest of the commands?

[stsewd]

It runs inside one

readthedocs.org/readthedocs/projects/tasks.py

Lines 449 to 456 in 83e31f8

	with self.setup_env:
	try:
	before_vcs.send(sender=self.version)
	if self.project.skip:
	raise ProjectBuildsSkippedError
	try:
	with self.project.repo_nonblockinglock(version=self.version):
	self.setup_vcs()

But again, that's not the problem. We still log the exception to sentry manually.

[humitos]

I'm talking about this one which does not seem to be ran inside a context manager:

readthedocs.org/readthedocs/projects/tasks.py

Line 243 in 83e31f8

self.sync_repo()

[stsewd]

Not really sure, we don't record that action as a build, so we don't need the all the stuff from the context manager. It doesn't seen related to this anyway. Both calls use the default env

readthedocs.org/readthedocs/vcs_support/base.py

Line 67 in 83e31f8

self.environment = environment or LocalEnvironment(project)

and don't use the context manager.

[humitos]

Let's merge and see what happen after the next deploy :)

[stsewd]

@humitos errors from that place disappeared, but now it's logging from another place (where we log manually too)

https://sentry.io/organizations/read-the-docs/issues/1209161216/?project=148442&query=is%3Aunresolved+logger%3Areadthedocs.doc_builder.environments&statsPeriod=14d

readthedocs.org/readthedocs/doc_builder/environments.py

Lines 580 to 623 in 557c875

	def handle_exception(self, exc_type, exc_value, _):
	"""
	Exception handling for __enter__ and __exit__.
	This reports on the exception we're handling and special cases
	subclasses of BuildEnvironmentException. For
	:py:class:`BuildEnvironmentWarning`, exit this context gracefully, but
	don't mark the build as a failure. For all other exception classes,
	including :py:class:`BuildEnvironmentError`, the build will be marked as
	a failure and the context will be gracefully exited.
	If the exception's type is :py:class:`BuildEnvironmentWarning` or it's
	an exception marked as ``WARNING_EXCEPTIONS`` we log the problem as a
	WARNING, otherwise we log it as an ERROR.
	"""
	if exc_type is not None:
	log_level_function = None
	if issubclass(exc_type, BuildEnvironmentWarning):
	log_level_function = log.warning
	elif exc_type in self.WARNING_EXCEPTIONS:
	log_level_function = log.warning
	self.failure = exc_value
	else:
	log_level_function = log.error
	self.failure = exc_value
	log_level_function(
	LOG_TEMPLATE,
	{
	'project': self.project.slug,
	'version': self.version.slug,
	'msg': exc_value,
	},
	exc_info=True,
	extra={
	'stack': True,
	'tags': {
	'build': self.build.get('id'),
	'project': self.project.slug,
	'version': self.version.slug,
	},
	},
	)
	return True

Looks it can be fixed by adding the exception in this list

readthedocs.org/readthedocs/doc_builder/environments.py

Lines 536 to 542 in 557c875

	WARNING_EXCEPTIONS = (
	VersionLockedError,
	ProjectBuildsSkippedError,
	YAMLParseError,
	BuildTimeoutError,
	MkDocsYAMLParseError,
	)

[humitos]

Good!

It is supposed the WARNING_EXCEPTIONS is not needed anymore after we added the throws argument in the celery task. Actually, there should be an issue saying that we have to remove it.

The right place to add the exception class is

readthedocs.org/readthedocs/projects/tasks.py

Lines 273 to 292 in 30e4955

	# Exceptions under ``throws`` argument are considered ERROR from a Build
	# perspective (the build failed and can continue) but as a WARNING for the
	# application itself (RTD code didn't failed). These exception are logged as
	# ``INFO`` and they are not sent to Sentry.
	@app.task(
	bind=True,
	max_retries=5,
	default_retry_delay=7 * 60,
	throws=(
	VersionLockedError,
	ProjectBuildsSkippedError,
	YAMLParseError,
	BuildTimeoutError,
	BuildEnvironmentWarning,
	RepositoryError,
	ProjectConfigurationError,
	ProjectBuildsSkippedError,
	MkDocsYAMLParseError,
	),
	)

[stsewd]

@humitos the class is already on the throws arg. We should remove the code that manually logs to sentry.