I have just recreated this same failure when trying to add a patch to a deployment that was about to start, but then was successful in adding the same patch to the last backport window on the page. Yeah for reproducible, but no joy yet as to what is actually causing things to break.

I also noticed that the tool is showing me deployment windows from today that have already passed their start time. This is not expected behavior either as the get_upcoming_windows method that generates that list is supposed to compare to datetime.datetime.now(datetime.UTC).

In T366794#9869005, @bd808 wrote:

I also noticed that the tool is showing me deployment windows from today that have already passed their start time. This is not expected behavior either as the get_upcoming_windows method that generates that list is supposed to compare to datetime.datetime.now(datetime.UTC).

This is caused by https://gitlab.wikimedia.org/toolforge-repos/schedule-deployment/-/blob/7b3b9ce3f3ebdb220995a48b95665cfa7ce363bf/src/deployments/forms.py#L81 where choices=get_backport_windows(), should instead be choices=get_backport_windows,. Note the difference of the function being called and storing the output in the first case and the function stored by reference to be called at form initialization time in the correct case. :facepalm:

I found the cause of @kostajh's update failure in the logs:

2024-06-06T12:36:24Z deployments.mediawiki DEBUG: Before: {{Deployment calendar event card
    |when=2024-06-06 06:00 SF
    |length=1
    |window=[[Backport windows|UTC afternoon backport window]]<br/><small>'''Your patch may or may not be deployed at the sole discretion of the deployer'''</small>
    |who={{ircnick|RoanKattouw|Roan}}, {{ircnick|Lucas_WMDE|Lucas}}, {{ircnick|Urbanecm|Martin}}, {{ircnick|awight|Adam}}, {{ircnick|TheresNoTime|Sammy}}
    |what={{ircnick|cmelo|Claudio Melo}}
* [config] {{gerrit|1038862}} Enable CampaignEvents extension on Igbo
{{ircnick|kart_|Kartik Mistry}}
* [wmf.8] {{gerrit|1039571}} CX: Fix translation container max width for large screens
{{ircnick|Gerges|Gerges Shamon}}
* [config] {{gerrit|1039612}} [mswiktionary] Change the default Sitename value to Wikikamus
{{ircnick|anzx}}
* [config] {{gerrit|1037006}} commonswiki: Enable numeric wgCategoryCollation
}}

This is the tool's view of the deployment window that @kostajh chose to add his change to. Note that it ends with a section for {{ircnick|anzx}}.

The tool's janky algorithm for figuring out where to insert the new change in the what list is:

def add_item_to_window(window, nick, name, item):
    logger.debug("Before: %s", window)
    marker = utils.build_ircnick(nick, name)
    search_nick = nick.lower()
    what = window.get("what").value
    insert_next = False
    for section in get_templates_by_name(what, "ircnick"):
        section_nick = section.params[0].lower()
        logger.debug("section: %s; nick: %s", section, section_nick)
        if insert_next or section_nick == INSTRUCTIONS_NICK:
            if not insert_next:
                # Create a new section
                what.insert_before(section, marker + "\n", recursive=False)
            what.insert_before(section, item + "\n", recursive=False)
        if section_nick == search_nick:
            # Found existing section for our user
            # We now want to insert before the next item.
            insert_next = True
    logger.debug("After: %s", window)

This algorithm assumes that the list of deployers in the window will always include an {{ircnick|irc-nickname|Requesting Developer}} entry. When that entry has been removed and the submitted nick is not already in the list the for loop will end without inserting anything new into the mwparserfromhell parse tree. Nothing after that checks to ensure that the tree changed, so the edit sent to Wikitech is a null edit as I speculated in T366794#9868262. MediaWiki will happily take a null edit and tell you things worked, but that doesn't generate a new revision or leave a trace that is visible on-wiki.

My algorithm needs to be fixed so that edits like https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=prev&oldid=2188927 don't blow things up. It also should add a validation step to ensure that the wikitext has actually changed before saving.

bd808 opened https://gitlab.wikimedia.org/toolforge-repos/schedule-deployment/-/merge_requests/6

Guard against various edit failures

bd808 merged https://gitlab.wikimedia.org/toolforge-repos/schedule-deployment/-/merge_requests/6

Guard against various edit failures

Mentioned in SAL (#wikimedia-cloud) [2024-06-06T22:21:36Z] <wmbot~bd808@tools-bastion-12> Built new image from d178f459 (T366794)

Mentioned in SAL (#wikimedia-cloud) [2024-06-06T22:22:32Z] <wmbot~bd808@tools-bastion-12> Restart to pick up new container image (T366794)