Builds for stable documentation are repeatedly duplicated

[pronovic]

Details

• Read the Docs project URL: https://readthedocs.org/projects/cedar-backup3
• Build URL: https://readthedocs.org/projects/cedar-backup3/builds/13236250/
• Read the Docs username: pronovic

Problem

I have been repeatedly running into problems where my stable documentation build is duplicated, and then the 2nd build fails. In one sense, this is ok, because the 1st build succeeds and the published documentation is correct. However, the documentation badge shows a failure, so it looks like the documentation is broken, which gives users a false sense about the state of the project.

Even though I've configured my email address for notifications, I don't get any email when this happens, so the badge looks wrong in GitHub until the next time I happen to notice it. Then I have to manually trigger another build of stable to fix the problem.

This is the only one of my projects that regularly runs into this problem. I've looked at configuration for this project vs. my other projects, and also double-checked what the webhook looks like in GitHub vs. other repos. Everything looks equivalent. So, I don't see an obvious reason why this project is having this problem but others aren't.

I did resync the webhook this morning, and it's possible that will make a difference, but it's too soon to be sure.

Preferred Outcome

One of three things would fix this for me:

1. Avoid triggering the duplicated build
2. Notify me when the duplicated build fails, so I can fix it
3. Duplicated build does not mark documentation as failed for the purposes of the badge

[stsewd]

Notify me when the duplicated build fails, so I can fix it

I think this was done on purpose.

Duplicated build does not mark documentation as failed for the purposes of the badge

I'm +1 on that.

So, for the original problem. Can you check that you don't have multiple webhooks in your project (from the github side)? Do you have an automation rule setup?

[pronovic]

Notify me when the duplicated build fails, so I can fix it

I think this was done on purpose.

Yeah, I got that sense from some further digging that I did.

Duplicated build does not mark documentation as failed for the purposes of the badge

I'm +1 on that.

So, for the original problem. Can you check that you don't have multiple webhooks in your project (from the github side)? Do you have an automation rule setup?

I only have the one webhook. As far as I know, I don't have any other automation rules - there is a GitHub workflow, but it does not build the documentation and does not interact with anything external to the repository.

[stsewd]

I checked the webhook responses from your project. There are 3 events from March 13.

• A push event to latest (we triggered a build)
• A new tag was created (we re-sync versions here)
• A push from the new created tag (we didn't do anything here)

So, a build is triggered to latest, then a re-sync task is called from there (we call re-sync on every build). And in the meantime another re-sync task is triggered by the webhook when the new tag is pushed.

And now we have two re-sync tasks running at the same time! And both try to activate and build the new stable version.

readthedocs.org/readthedocs/builds/tasks.py

Lines 317 to 325 in 5013d89

	if promoted_version and new_stable and new_stable.active:
	log.info(
	'Triggering new stable build: %(project)s:%(version)s',
	{
	'project': project.slug,
	'version': new_stable.identifier,
	}
	)
	trigger_build(project=project, version=new_stable)

I'm not sure if there is an easy way to fix this, but an easy one to fix would be to ignore duplicate builds from the badge.

[pronovic]

Yeah, that makes sense as a root cause. When I release a new version of my code, I always push some local changes (new version number, etc.) and a new tag at the same time.

If you can ignore the duplicate builds in the badge, I think that would solve my immediate problem.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pronovic]

Hey @stsewd, has there been any movement on this? I would prefer to avoid having this issue marked as stale, since it is still a potential problem AFAIK.

[rockandska]

Hi,

Just hit the same problem when pushing a new release (push CHANGELOG + push tag).
Not really a problem in fact, but it is disturbing (and consume resources) to see "Failed" when it is only a matter of duplicated build.

[humitos]

Is this still an issue? If so, can you share what are the minimal steps to reproduce this issue so I can debug it properly?

[pronovic]

I just looked at the build history for this repo. The last failure I got was back on Nov 15, 2021. So, this behavior was happening pretty consistently between June-November of 2021, but something seems to have changed since then and it's stable now.
@rockandska's comment above is from about a week after my last failure, so possibly there are other folks still seeing this? But it's currently not a problem for me on any of my projects.

[humitos]

Great! We've changed a lot of stuff in our backed with things related to his we clone and handle these events, so I wouldn't be surprised if this problem was fixed with those changes.

I will close the issue if there are no more reports about this issue in a few days from now.