[Bug] Pueue status shows job as Failed but the command ran successfully

[graphixillusion]

Describe the bug

I'm getting Operation Failed in the status view but the command was executed successfully.

Steps to reproduce

pueue add -- robocopy . d:\ Somefile

At the end of the robocopy command, pueue status shows the job as Failed

Debug logs (if relevant)

No response

Operating system

Windows 11 23H2

Pueue version

v3.4.1

Additional context

No response

[Nukesor]

Can you provide any more info? This is very little to work with.

Debug logs of the daemon and a copy/screenshot of your pueue status output would already help a lot.

If it's something obvious I might be able to fix it, otherwise you might need to investigate yourself or ping somebody that worked on the windows code. I don't have any windows machine any longer and rely on the community to support the windows compatibility.

[graphixillusion]

Here the status:

Group "default" (1 parallel): running
───────────────────────────────────────────────────────────────────────────
 Id   Status       Command                   Path      Start      End
═══════════════════════════════════════════════════════════════════════════
 0    Failed (1)   robocopy . d:\ testfile   C:\Temp   23:57:48   23:57:50
───────────────────────────────────────────────────────────────────────────

This is the log of the job id (the file is indeed copied)

pueue log 0
┌────────────────────────────────────┐
│ Task 0:    failed with exit code 1 │
└────────────────────────────────────┘
Command: robocopy . d:\ testfile
   Path: C:\Temp
  Start: Tue, 4 Jun 2024 23:57:48 +0200
    End: Tue, 4 Jun 2024 23:57:50 +0200

output: (last 15 lines)

-------------------------------------------------------------------------------

                           1    C:\Temp\
            Nuovo file                 0        testfile

-------------------------------------------------------------------------------

              Totale   Copiato  IgnorateNon corrispondentiNon riuscitaSupplementari
Directory:         1         0         1         0         0         0
     File:         1         1         0         0         0         0
     Byte:         0         0         0         0         0         0
   Durata:   0:00:00   0:00:00                       0:00:00   0:00:00
   Terminato: martedì 4 giugno 2024 23:57:50

I ran the command pueued -d, how to get the log of the daemon?

p.s. In one of my tests i noticed that if the file i'm copying is already present in the destination folder, the pueue marks the job as successfull

[Nukesor]

Failed(1) means that the command exited with a 1 code.

I'm not sure how this works on windows, but a command can mostly work just fine and still exit with a non-zero exit code.

My first approach would be to run the command without pueue and check the exit code.

[graphixillusion]

Mmm that's the problem then. In robocopy exit code=1 means all files were copied successfully according to the table you can find here: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy

[Nukesor]

So, I couldn't really find anything about a general meaning of return codes in windows shells.

I found this site, which looks very similar to the unix return codes, where 0 is the only code that actually signals that everything is fine. Everything that's non-zero indicates some kind of error.

If that's indeed the case, Robocopy doesn't adhere to exit code standards.

[graphixillusion]

Yep, it seems that robocopy doesn't follow the standard in this case. It could be implemented a new section in the config file where you specify exceptions based on the name, like

robocopy.exe: use_custom_exit_code: true exit_code_successfull: 1 pueue_status_custom_message: Check the log

In all the other cases where the exit code is not equal to 1, a custom message in the status appears instead Failed. Something like check the job log or similar

[Nukesor]

To be honest, I probably won't do this, as pueue accepts any shell input. So you could theoretically add the robocopy call behind a && or somewhere in a multi-line script and it would be incredibly hard to detect whether robocopy is actually the command that failed.

We wouldn't know which command actually failed and having custom overrides for each script/command isn't really an option for me. It's too much work just to handle projects that don't adhere to standards.

[Nukesor]

Closing as won't do :)

Cheers