AL-Go
AL-Go copied to clipboard
microsoft
Failed publish attempts prevent next publish attempt
Is there a procedure to get around this problem:
I run Publish to Environment, which fails due to an authentication error. I fix the authentication error (refresh the impersonation token) and run Publish to Environment again. This now fails with "Unprocessable Entity A duplicate package ID is detected."
What is happening is the failed publish is leaving a package on the server, even though it is not published and does not appear in the Extension Management list.
Now I have to increase the version number or force another build to get a higher version number. And even this sometimes fails with the same Unprocessable Entity error--for example, if I run CI/CD to get another build artifact and then try to deploy using "latest."
We are not using releases, because no Production environments, per your recommendation.
How should we be handling this? Is there some way around this "phantom" package problem?
Nope. That's the thing. It never shows in Extension Management. Even when GitHub is saying a duplicate package exists, you cannot see any such extension in BC.
Very strange that you are able to "publish something" with an expired refreshtoken... I mean, with an expired refreshtoken you should never get inside.
Would it be possible for me to see the full logs of two Publish To Environments (the one with the expired token) and the one failing afterwards?
I have reported the same issue here: https://github.com/microsoft/AL-Go/issues/557
It's a problem with 'dev endpoint' deployments. I 'solved' by swtching to s2s authentication (see Freddys' blog ), then it deploys app in PTE scope, and skips apps with the same version. It would be nice, if AL-GO could check if that version is already installed or not for 'dev scope' as well.
The downside 'pte scope' approach, you get tones of old app versions in "Installed Extensions" view. This is a view from a few days. You can imagine, how much old version accumulates there for an active project.
@gntpet got it, but @buzzwick states that this happens when the authentication has expired - meaning that the first deploy should not succeed. That's what puzzles me on this one.
I can clarify further—if a deployment to an environment fails (say for example an expired token), the app is “uninstalled “ from the environment. That is, it is no longer available in the UI, and does not show in the Extension Management list.
And yet, a subsequent Publish (after renewing the token) fails with “duplicate package id found.”
Get Outlook for iOShttps://aka.ms/o0ukef
From: Freddy Kristiansen @.> Sent: Thursday, January 11, 2024 6:16:34 AM To: microsoft/AL-Go @.> Cc: David Baldwin @.>; Mention @.> Subject: Re: [microsoft/AL-Go] Failed publish attempts prevent next publish attempt (Issue #872)
**CAUTION: This email originated from outside of CAI Software, LLC. Do not click links or open attachments unless you recognize the sender and are expecting the attachment or link.
@gntpethttps://github.com/gntpet got it, but @buzzwickhttps://github.com/buzzwick states that this happens when the authentication has expired - meaning that the first deploy should not succeed. That's what puzzles me on this one.
— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/AL-Go/issues/872#issuecomment-1886916140, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJTBZITYSUTPEV4VKD5UQKLYN7CZFAVCNFSM6AAAAABBVITS3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBWHEYTMMJUGA. You are receiving this because you were mentioned.Message ID: @.***>
@buzzwick - based on your description, I tried to create a repro which does exactly this.
I cannot repro this problem. When AL-Go fails to get an access token from the Refreshtoken. it will never actually contact the server - meaning that it cannot uninstall nor publish anything.
I do however trust that you are seeing something - so something else must be happening here.
Maybe you have multiple environments and some fail and some passes on the first attempt - and then on the second attempt, the ones that passed on the first failed?
We do have multiple environments, but I see this problem even when deploying to a single environment.
I will try to do some testing against a single controlled environment and see if I can reproduce it at will. I certainly have no trouble reproducing it when I do not want to!
If you have some outputs from the logs (one where it had expired and one after updating) - I would like to see them.
Working on it. I have to wait 90 minutes for this new auth token to expire, so that I get the same error.
No luck. I deliberately let our authcontext expire, Deploy failed, but apps are still in place. If I run into the problem again, I should be able to capture a log from the most recent deploy and also from the last successful deploy and offer them for comparison.
This might be a result of BC updates being pushed out by Microsoft. So far as I know, AL-Go can only publish extensions as Dev (although the post above indicates that using S2S authentication would enable PTE deployment). Dev extensions are "uninstalled" by MS BC updates. But they are not actually removed--"cleaned"-- from the environment. So this could be why successive attempts to deploy, without incrementing either a build or a version number, fail. Continuing to test.
That is a good observation - I will ask the moderndev team what happens in this case.
So here is a possible example of successful vs. failed deployments. Our client updated BC on three of their sandbox environments. This uninstalls our main extension, because we use the Dev endpoint to deploy. I ran Publish to environment on all three environments simultaneously. It succeeded on two; failed on one. I have included a success log archive and a fail log archive. It would seem that all three should succeed if two succeed; the failed environment should, if anything, have been behind the other two environments in terms of version. logs_failed.zip logs_succeeded.zip
Now we can reproduce the scenarios I described earlier: An attempt to deploy a later version (minor version increment) fails due to authentication failure. A successive attempt to deploy the same version fails "because the same package ID already exists in a published extension." Which suggests that somehow the package is being "left" at the environment but not installed (it is not visible in Extension Management), or some version log is being updated without installing the extension. Here are those two logs: the first authentication failure log and the second "unprocessable entity" log. duplicate-package-id.zip authentication-failure.zip
Update: Then we do a CI/CD to produce a higher build number. It deploys to all the other environments (but not to the UAT environment, because we want to control those releases). But then a run of Publish to Environment, using "latest," fails because "duplicate package ID found." Which makes us wonder how the version number on the UAT environment is getting updated, ahead of any attempt that we can see to actually deploy to that environment. Here is that log, just for good measure:
Okay, definite pattern: Increment Version Number increases the minor version and then deploys to eight of the nine environments. Immediate attempt to deploy the newly-incremented version to the ninth environment fails with the duplicate package ID error. Here is that log: after-incremnet-version-no.zip
And here is our settings file: settings.json
Thanks - this gives me a hint - and definitely closer to a solution. On the UAT you are using a refreshtoken as auth - is this a PROD environment or a Sandbox environment?
On the other 8 environments - are they sandbox environments or production environments? Are you using RefreshToken as authentication or ClientId/ClientSecret?
Thanks
All of these environments are Sandbox--we are currently not deploying to any Production environments. All use RefreshToken (New-BcAuthContext); it is only the UAT, JMSandbox and JMDEV that have expirations on that authentication set to 90 minutes--that is why they fail so often, because I forget to renew every time I run an Action. Last night I removed the "continuousDeployment = false" from the Settings file for JMUAT. That way it went ahead and deployed during a CI/CD run, instead of being skipped but spiking the ability to deploy manually.
All of the environments are CI/CD, except for UAT which is "deploy only on demand." So for the moment I am deleting that environment, but leaving the authcontext references in place, so when it comes time to deploy I can just add the environment again. A rude hack, but works for now.
Some more examples of this sequence; I am pretty sure that a failed publish "pulls" (as in it disappears from the Extension Management list) the installed version of the app, but leaves it hanging around such that a successive attempt to publish the same version fails with the "Duplicate Package ID" message. Here are two logs: "Unprocessable entity" is a failure to publish (but not because of authentication), and "Duplicate Package ID" represents the subsequent attempt to publish the same version.
Duplicate package ID.zip Unprocessable entity.zip
Thank you. That will be a great relief, because our client is breathing down our necks to have "stable" environments and deployments. In the meantime--so far I have not discovered a way to initiate a Build to generate artifacts, without initiating some Deploy sequence. Is there one?
I keep thinking about the sequence--the first deploy fails for "unprocessable entity," and then the second attempt to deploy the exact same version fails--presumably because the "unprocessable entity" has in fact been installed somewhere. Or something. Then once we get the versioning incremented, the exact same code deploys, and the "unprocessable entity" problem magically disappears.
More data: Log below records a session where an "unprocessable entity" error definitely uninstalled the DEV app from the target environment. unprocessable entity (2).zip
And for the record: an immediate deployment of the same code, same version from VS Code succeeds. No "unprocessable entity" error.
I have a fix for this, which you can try out, but it requires you to use a development branch of AL-Go for GitHub.
If you run Update AL-Go System Files with freddydk/AL-Go@unprocessible then it shouldn't happen anymore.
If you can confirm this - then I can create a PR on main with this, thanks
Updated the system files and ran a CI/CD (builds from the AL-Go update failed; I had to remove our codesigning flags because that's not working yet). But that failure did not uninstall the app from the environments. The CI/CD was successful on two of the three environments for one client. Failed on their "Sandbox" environment, with "unprocessable entity". Publish to that environment failed with "zero arguments" error. Second Publish to that environment succeeded; same artifact. Logs are below, in order. Seems like a partial success, at least.
1_UnprocessableEntity.zip 2_ZeroArguments.zip 3_Success.zip
I have added some additional logs when/if this happens again, that should give me some more info. Please post new logs when possible (and add info about the environment name that fails:-)) Thanks
I will try to be as diligent as possible about tracking what happens, and will post logs. We have several other clients with sandbox environments that we are deploying to, but no one else has (so far) called to complain that our app has disappeared from their environment. Just this one client and their three sandboxes--and not always the same one. The other client deployments are all failing for known authentication reasons--so far no "unprocessible entity" failures from them.
I will close this bug for now. If this re-appears, please create a new bug with full log for me to investigate (with additional info) For the unpublish, please see #409 and https://github.com/microsoft/navcontainerhelper/issues/2808