What is the file order for an sfdx force:source:push (and why is a sfdx force:source:push silently failing)?

Question

I get a failure when doing a sfdx force:source:push (sfdx-cli/7.170.0) with no additional helpful information (in the console or in $HOME/.sf/sf.log) but always at this point:

DEPLOY PROGRESS | █████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 278/2164 Components
DEPLOY PROGRESS | █████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 278/2164 Components
DEPLOY PROGRESS | █████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 278/2164 Components
DEPLOY PROGRESS | ██████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ | 335/2164 Components
DEPLOY PROGRESS | ████████████████████████████████████████ | 0/0 Components
Updating source tracking... done

so understanding how the components are ordered would allow me to examine components 336, 337, 338 etc more carefully than the others and perhaps identify the problem.

I do get a gack that I could get Salesforce support to look at. And given that sfdx force:source:deploy works with no problem, this may be an sfdx bug.

But what is the file order used for push?

PS

If the file order is the one reported after a sfdx force:source:deploy runs, then that corresponds in my case to about half way through the classes and at that point there are no recent changes in my files.

PPS

I did create a support request and got this "received two objects that are exactly the same" information; I will ask if there is any evidence of which components were being handled at the time in the log before this point.

gslog`20221007141045.602`4ljDhuyn1fxA-vX2-swQI-`8609`0`0`0`````6f8a8dcab5a8cb7d`8037392386766719869``0`fe:034`238.18.34```00D5C0000009GXn`0055C000004bCrr``486193339-46120`208639346`default-racNode-3--MqFrameworkBaseHandler-session(490732933)-processor-threadId-8609````SEVERE``common.api.soap.metadata.core.deploy.AbstractFileBasedMetadataWorker`handleThrowable
`java.lang.IllegalStateException: bulkDml: received two objects that are exactly the same (==) at common.udd.object.BulkDml.validateEntityObjects(BulkDml.java:112)


"`java.lang.IllegalStateException: bulkDml: received two objects that are exactly the same (==) "

Answer 1

You've misunderstood how this command works. It is similar to the MDAPI in that regards; all the contents are packaged up, sent to the server for validation, then enters a polling loop to check the status of the deploy with DeployResult. All it's really doing is showing you numberComponentsDeployed / numberComponentsTotal. In other words, it doesn't know about the specific order of files processed. You can check Setup > Monitoring > Deployment Status to try and get additional information regarding the deployment, and you may also have extra information in ~/.sfdx/sfdx.log or %USERHOME%/.sfdx/sfdx.log, depending on your OS and shell.

Answer 2

With the gack detail from Salesforce that the push error originated from:

java.lang.IllegalStateException: bulkDml: received two objects that are exactly the same (==)

but no specific component name, the question became "how can you have such a situation"?

With a single source code root i.e. only the force-app/main/default I don't think you can. But this project has two source code roots, and doing a pull from the org I had pulled a duplicate copy of a field that was in the second root into the force-app/main/default root. (Personally I favour the KISS one root approach but I didn't create this project.)

Luckily the second source code root had only a small amount of content so I found the duplicate by manual means. Otherwise I would have had to create a script to look for duplicates. Hopefully Salesforce will improve the handling of this case in the future so that the duplicate component name is passed back through SFDX and an error that took me several days to figure out will be made quick to identify.