Skip to content

[WIP] Fix duplicate Codeunit ID collision by changing ID to 4610#7699

Draft
Copilot wants to merge 1 commit into
mainfrom
copilot/fix-codeunit-4581-duplicate-id
Draft

[WIP] Fix duplicate Codeunit ID collision by changing ID to 4610#7699
Copilot wants to merge 1 commit into
mainfrom
copilot/fix-codeunit-4581-duplicate-id

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Apr 15, 2026

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

Fix failing PR build due to duplicate object ID collision: Codeunit 4581 is defined in multiple apps (Sales Order Agent and External File Storage ...). Change the conflicting codeunit ID from 4581 to 4610 in the relevant app in microsoft/BCApps.

Context from failing job (ref a85859f): installation of Sales Order Agent fails with error: "The application object of type 'CodeUnit' with the ID '4581' is defined in multiple apps" and the workflow aborts from build/scripts/ImportTestDataInBcContainer.ps1 line 93.

Task:

  1. Locate the AL object defining codeunit 4581 in this repo that is conflicting (likely in an app related to External File Storage, or whichever app in this PR introduces the duplicate).
  2. Change its object ID from 4581 to 4610.
  3. Update all references to that codeunit ID throughout the repo (e.g., CODEUNIT::... references, permissions, tests, app.json if needed, any .al usages).
  4. Ensure compilation/tests still pass.

Notes:

  • Use the repo contents at/around the PR branch; use default branch if necessary, but ensure the fix applies to the PR.
  • Keep changes minimal and localized.
  • If there are multiple codeunits with ID 4581, only change the one that conflicts with Sales Order Agent (not Sales Order Agent itself unless that is the intended change).
  • Add/adjust comments only if necessary.

Reference URL: https://github.com/microsoft/BCApps/actions/runs/24447802123/job/71433070660?pr=5833

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The job fails while importing/installing apps into the BC container because Sales Order Agent cannot be installed due to an object ID collision:

The application object of type 'CodeUnit' with the ID '4581' is defined in multiple apps. The apps are: Sales Order Agent by Microsoft 29.0.48994.0; External File Storage - ...

After 3 retries, the pipeline aborts and the step errors out from:

  • build/scripts/ImportTestDataInBcContainer.ps1: line 93 (per the log)
  • Final error: Failed to install apps: Sales Order Agent

What to change (solution)

You need to ensure that only one app providing Codeunit 4581 is present/installed during the container app installation phase. In practice that means adjusting the app set (test data import / dependency installation list) so the pipeline does either:

Option A (preferred): Don’t install Sales Order Agent in this job

If Sales Order Agent is not required for the tests/data import being executed in this PR build, exclude it from the “install apps in container” list used by ImportTestDataInBcContainer.ps1.

Code suggestion (in build/scripts/ImportTestDataInBcContainer.ps1, around the failing install block near line ~93):
Add a guard that filters out Sales Order Agent when an app with the conflicting object is present (or always, if it’s never needed here). Conceptually:

# Example: remove Sales Order Agent from the install list for this pipeline
$appsToInstall = $appsToInstall | Where-Object { $_.Name -ne 'Sales Order Agent' }

If the script installs from a dependency/app artifact list, apply the filter there (before calling the install/publish routine).

This will allow the rest of the apps to install and the job to proceed.

Option B: Ensure External File Storage is not published/installed at the same time

If Sales Order Agent is required, then remove/avoid the other app that also defines Codeunit 4581 (the log shows it as “External File Storage - …”). That typically means:

  • removing it from the dependency set being published into the container, or
  • preventing it from being installed/published in that test run.

The key is: only one of the two apps may be present with that object ID.

Option C (structural fix): Change the object ID in one of the apps

If your PR introduces/changes the “External File Storage …” app (or if you control it), the long-term correct fix is to move the conflicting Codeunit off ID 4581 into a valid range for that app, and update references accordingly.

This is the cleanest from a product perspective, but it’s also the most invasive.

Why this is the right fix

The failure is not a transient install issue; it’s a Business Central rule: duplicate object IDs across installed/published apps are not allowed. Retrying won’t help (as seen in attempts 1–3). The pipeline must avoid publishing/installing both apps that contain Codeunit 4581.

Quick validation

After applying Option A or B, the failing step should no longer hit:

  • Attempt X to install Sales Order Agent ... CodeUnit 4581 is defined in multiple apps
    and the script should not end with:
  • `Failed to install apps: Sales Order ...

This pull request was created from Copilot chat.

Copilot stopped work on behalf of JesperSchulz due to an error April 15, 2026 13:18
Copilot AI requested a review from JesperSchulz April 15, 2026 13:18
onbuyuka pushed a commit that referenced this pull request Jun 1, 2026
## Summary

Adds a scheduled workflow that automatically labels open PRs whose
GitHub Actions workflow runs are in the `action_required` state — i.e.
waiting for a maintainer with write access to click *Approve and run*.

This lets us easily find PRs that need a manual approval click via:

```
is:pr is:open label:needs-approval
```

…or:

```
gh pr list --repo microsoft/BCApps --label needs-approval
```

## How it works

- **Trigger**: `cron: '*/15 * * * *'` + `workflow_dispatch` (with
optional `whatIf` dry-run input). Mirrors the pattern in
`CleanUpStalePRChecks.yaml`.
- **Reconciliation** is idempotent on every run:
1. Ensures the `needs-approval` label exists (creates it if missing,
color `#FBCA04`).
2. Fetches workflow runs with `status=action_required` from the Actions
API.
3. Resolves each run to a PR number (with a fork-PR fallback via
`commits/{sha}/pulls` since fork-PR workflow runs have an empty
`pull_requests` array).
  4. Computes the diff against PRs currently carrying the label.
5. Adds the label to new awaiters, removes it from PRs no longer
awaiting (approved, or PR closed).
- Guarded by `if: github.repository_owner == 'microsoft'` so forks don't
run it.
- Follows existing repo conventions: pwsh, SHA-pinned
`actions/checkout`, composite action under `.github/actions/`, GitHub
step summary.

## Files

- `.github/workflows/LabelPRsAwaitingApproval.yaml` — workflow (schedule
+ manual)
- `.github/actions/LabelPRsAwaitingApproval/action.yaml` — composite
action wrapper
- `.github/actions/LabelPRsAwaitingApproval/action.ps1` — reconciliation
logic

## Validation

Dry-run against `microsoft/BCApps` (using `-WhatIf`) successfully:
- Detected 100 `action_required` workflow runs
- Deduped to 5 unique open PRs awaiting approval (#7410, #7699, #7843,
#8165, #8313)
- Correctly computed: would add label to 5 PRs, remove from 0

## Permissions

The workflow requests minimum required scopes:
- `actions: read` — list action_required runs
- `contents: read` — checkout the composite action
- `issues: write` + `pull-requests: write` — manage the label

Uses `github.token` — no additional secrets needed.

## Caveats / future enhancements

- Page size is 100 with no pagination. Given BCApps' volume of
currently-awaiting runs, this is well within bounds; can be paginated
later if needed.
- Latency is up to 15 minutes. A future enhancement could add
`workflow_run: types: [completed]` for near-instant labelling.



[AB#637233](https://dynamicssmb2.visualstudio.com/1fcb79e7-ab07-432a-a3c6-6cf5a88ba4a5/_workitems/edit/637233)

---------

Co-authored-by: Magnus Hartvig Grønbech <magnushar@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions github-actions Bot added the needs-approval Workflow runs require maintainer approval to start label Jun 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-approval Workflow runs require maintainer approval to start

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants