dispatch init throws error only on Azure DevOps

[devedse]

Tool

Name: Dispatch Version: 1.7.1 OS: Windows server 2019

Describe the bug

I'm currently creating an Azure DevOps pipeline to automatically create the dispatch model. However when I run the following PowerShell script I keep running into an error that I don't get when I run it locally:

- deployment: Deploy_Dispatch_Model
  environment: '${{ parameters.ENVIRONMENT }}'
  pool:
    vmImage: 'windows-2019'
  strategy:
    runOnce:
      deploy:
        steps:
        - task: PowerShell@2
          name: DeployDispatch
          inputs:
            targetType: 'inline'
            errorActionPreference: 'continue'
            script: |
              npm install -g botdispatch

              Write-Host "Running dispatch init..."

              Write-Host "dispatch init -n CHATBOT-${{ parameters.ENVIRONMENT }}-Dispatch --luisAuthoringKey $(LuisAuthoringKey) --luisAuthoringRegion westeurope"
              & dispatch init -n CHATBOT-${{ parameters.ENVIRONMENT }}-Dispatch --luisAuthoringKey $(LuisAuthoringKey) --luisAuthoringRegion westeurope

              Write-Host "File content (Just as a test):"
              Get-Content CHATBOT-DEV-Dispatch.dispatch

              Write-Host "Adding LUIS / QnA models..."

              & dispatch add -t luis -i $(LuisGeneralModelAppId) -n CHATBOT-DEV-General -v $(LuisGeneralModelVersion) -k $(LuisAuthoringKey)
              & dispatch add -t qna -i $(QnAMakerKBId) -n CHATBOT-${{ parameters.ENVIRONMENT }}-KB -k $(QnAMakerKBEndpointKey)

This script shows the following logging:

"C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'd:\a\_temp\e6aa19d9-d94b-4583-ba7d-a3038400299e.ps1'"
C:\npm\prefix\dispatch -> C:\npm\prefix\node_modules\botdispatch\bin\dispatch.js
+ botdispatch@1.7.1
updated 1 package in 1.456s
Running dispatch init...
dispatch init -n CHATBOT-DEV-Dispatch --luisAuthoringKey 15*********3c --luisAuthoringRegion westeurope
node.exe : CHATBOT-DEV-Dispatch.dispatch created
At C:\npm\prefix\dispatch.ps1:15 char:3
+   & "node$exe"  "$basedir/node_modules/botdispatch/bin/dispatch.js" $ ...
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (CHATBOT-DEV-Dispatch.dispatch created:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

File content (Just as a test):
{
  "authoringRegion": "westeurope",
  "hierarchical": true,
  "useAllTrainingData": true,
  "dontReviseUtterance": false,
  "copyLuisData": true,
  "normalizeDiacritics": true,
  "services": [],
  "serviceIds": [],
  "authoringKey": "15*********3c",
  "version": "Dispatch",
  "region": "westeurope",
  "type": "dispatch",
  "name": "CHATBOT-DEV-Dispatch"
}

Everything seems to work, however this is only because I changed set errorActionPreference: 'continue'. If I leave this as default (Stop) then the PowerShell script simply exits after the 'RemoteException' message.

As you can see I also added a Write-Host of the exact command that's executed. If I execute that command locally everything works fine:

PS C:\XGitDll\dispatchmodel\test2> dispatch init -n CHATBOT-DEV-Dispatch --luisAuthoringKey 15*********3c --luisAuthoringRegion westeurope
CHATBOT-DEV-Dispatch.dispatch created
PS C:\XGitDll\dispatchmodel\test2> $LASTEXITCODE
0

I really don't understand how this command can be working flawlessly on my local machine, where it seems to fail on the Azure DevOps environment even though it did create the .dispatch file correctly.

I did also try to run the same script with CMD, but this resulted in a somewhat similar situation where the script failed.

To Reproduce

Execute the .yml pipeline in Azure DevOps yml pipelines

Expected behavior

I expect the .dispatch model to be created even when errorActionPreference is set to stop.

Screenshots

N/A

Additional context

N/A

[bug]

[Zerryth]

@devedse I noticed that you're using PowerShell commands, but in your YAML you specify script

script: |
             npm install -g botdispatch

              Write-Host "Running dispatch init..."

(^ wow spacing is weird copying and pasting 😅 )

Anyways, I think you should switch script to be a powershell/pwsh task, because per Azure DevOps Services documentation, when you use script, it's a keyword shortcut for cmd.exe on Windows and Bash on other platforms.

And if that's the case PS commands don't necessarily work in cmd:

---

Let us know if switching to PS gets you passed that error, and JJ (whom we're having trouble assigning the issue to currently) will help follow-up if that doesn't work

[devedse]

Hi @Zerryth, I am using that :), you might have overlooked it, but this is infact a PowerShell task:

        - task: PowerShell@2
          name: DeployDispatch
          inputs:
            targetType: 'inline'
            errorActionPreference: 'continue'
            script: |

[Zerryth]

ha! so you are. hmm...we'll dig into this further then

[devedse]

The strange thing is that if I'm simply setting the powershell task to continue on error everything works fine, even though some errors are printed out.

I've ran into something similar before where docker-compose write logs to the STD-ERR log which causes Azure DevOps to detect an external command as failing. A discussion started then whether or not 'non failing logging' should be written to the STD-ERR log, but they had their reasons I suppose.

Could it be that the dispatch tool is encountering a similar problem?

[jwiley84]

Hi @devedse

The strange thing is that if I'm simply setting the powershell task to continue on error everything works fine, even though some errors are printed out.

Does this mean the dispatch is successful, even though errors are show?

[devedse]

Yep, exactly that

[daveta]

@tsuwandy : Can you take a look?

[tsuwandy]

@devedse , did you include the optional parameter "--remote true"?

[devedse]

@tsuwandy , I did not do that yet. It's a bit hard for me to test now because I won't be on the customer project this week. What does --remote true do?

[tsuwandy]

@devedse, dispatch cli takes stdin input and for some reason running it remotely from powershell has a similar effect of calling it with stdin. Passing “—remote true” tells the cli to ignore stdin.

[peterinnesmsft]

@devedse any updates on this? Wanted to see if this has helped resolved your issue, or if further support is needed from us.

[devedse]

I'll ask my colleague @rufus1123 to chip in.

[Rufus1123]

@tsuwandy I have added the "--remote true" flag to both the dispatch init command and the dispatch create command. (According to the documentation, only dispatch create and dispatch refresh support this flag.) The error now shows up at both the init and create commands:

[tsuwandy]

@Rufus1123/@devedse, is the dispatch app actually created after create command? Hard to see from screenshot. Thanks!

[Rufus1123]

Yes, a functioning dispatch model is created.

[tsuwandy]

@Rufus1123 , thanks. So the command "init" and "create" actually finished and created a functioning dispatch app, correct? I'm guessing the "error" is because the CLI writes to std error so that it could write a LUIS json of the dispatch app at the end of "create" command so that it could be piped in to a msbot/luis CLI (now deprecated in favor of BF CLI).

Sounds to me that you could use the dispatch app created, so I'll close this issue. Please reactivate otherwise. Thanks!

[Rufus1123]

@tsuwandy The dispatch app is created yes, but it's still a bug in the tool. We only got it to work by setting the errorActionPreference: 'continue' setting for the whole script. There might be other commands in the script that should stop the execution of the script when there is an error. Fortunately for us, that's not the case at the moment, so we can use this as a work-around. Also, the message that is posted ("RemoteException" / "NativeCommandError") looks like an error message, not trace/information that happens to be written to std.error. If there's no error, I think this error message shouldn't be printed.

[tsuwandy]

@Rufus1123, thanks for the update. "RemoteException" / "NativeCommandError" is not coming from the CLI, so I'm guessing it's due to CLI writing to std error and this is powershell behavior.