How to push changes to a GitHub branch after PR is already in the merge queue?

Question

I have a script that automates Azure subscription creation by opening PRs across two different GitHub repositories.

Repositories & File Structure:

Repo 1 - subscription.yaml

---
name: "Contoso - NonProd - Sub-Test-51"
subscriptionId: "subscription_guid_placeholder"
default_subscription_access_entra_group: "azure-sub-entra_id_placeholder"
tags:
  owner_team: "infra-team"
parent_management_group_id: "/providers/Microsoft.Management/managementGroups/CONTOSO-NONPROD"

Repo 2 - azure-sub-subscription_guid_placeholder.yaml

---
description = Users with access to `Contoso - NonProd - Sub-Test-51` Azure subscription
group = contoso/infra-team-members

How the Process Works

1. A PR is opened in Repo 1 with subscription.yaml.
2. Once approved, it enters the merge queue.
3. A deployment app (running in an internal Kubernetes environment, not GitHub Actions) provisions the Azure subscription.
4. Only after the deployment is complete, the actual subscriptionId is known.

Goals

• Before the PR is merged, populate the subscriptionId field in subscription.yaml.
• Name the file in Repo 2 using the last part of the subscriptionId GUID (sub_id.split('-')[-1]), e.g., azure-sub-4e2c4a261dde.yaml.
• Create an Entra ID group with the same name.

Challenges

• The merge queue branch is read-only, so I can't push changes directly.
• If I push updates after deployment, GitHub removes the PR from the merge queue.
• I need everything to happen within one PR rather than separate steps.

Ideas I've Considered (But Don't Like)

1. Maintain an External State (e.g., Database or Azure Table Storage)

• Store sub_name, sub_id, and file_path during deployment.
• Populate missing subscriptionId values in later deployments.
• Issue: Handling Repo 2 separately makes the process inconsistent.

2. Push Changes from the Deployment App to My Own Branch

• Let GitHub remove the PR from the merge queue, then trigger another deployment.
• Issue: Not sure how to cleanly re-trigger without re-deploying the same thing.

3. Use an Azure Subscription Tag to Store the File Path

• Add the tag during the subscription creation deployment.
• Fetch missing subscriptionId values in subsequent deployments.
• Issues:
  • Many users have Contributor access and can modify or remove tags.
  • Also faces the same problem as Repo 2.

4. Push Changes to a Different Branch, Auto-Approve, Deploy, and Merge

• Essentially creates a separate workflow for the update step.

Best Approach?

Tbh this might not even be possible would be good to know if anybody knows the best way to achieve this while keeping everything within a single PR?