This is expected behavior of the call when using the asychronous call when publishing workbooks. Per the following snippet from the Tableau Product Help guide.
Note: When using this method to query the progress of asynchronous workbook publishing, progress will switch from 0 when the job is in-progress to 100 when it is complete, finishCode will switch from 1 when the job is in-progress to 0 when it is complete, and no
<statusNotes>elements are provided.
Hope this helps!
Thanks for your response. You are correct that this is the current behaviour of the asynchronous workbook publishing operation, however my point is that unlike the synchronous publishing operation (and when publishing using tabcmd) the Query Job function does not provide any meaningful feedback on whether the publish operation actually succeeded or failed.
For example, let's say embedded within a workbook I am trying to publish there's a problem with a data source connection (e.g. wrong password):
1) when I try to publish using tabcmd, the operation fails and tabcmd returns an ODBC error message indicating login failed - this points the user directly to the root cause
2) when I try to publish using REST API synchronous publishing method (&asJob=false), the publish API call returns a 400 Bad Request error with no further details - at least it indicates to the user something went wrong, even if no specific error information is included for further diagnosis
3) when I try to publish using REST API asynchronous publishing method (&asJob=true), the QueryJob API call returns progress=100 and finishCode=0 even if the publish operation itself failed due to the same ODBC error, the user is never told of an error and the workbook never makes it into the library.
So hopefully you can now see my point about the discontinuity in expected functionality and why I feel the REST API asynchronous publish operation is broken/lacking, especially when I can see through Wireshark that the undocumented API which tabcmd uses already does all this.
FYI I've raised a support case to have this escalated to the devs for assessment. Hopefully any others who have come across this issue will benefit from understanding the current limitations.
Thanks for providing the additonal information and submitting the idea!