Cli: force:source:tracking:reset not resetting

[yippie]

Summary

running sfdx force:source:tracking:reset does not reset tracking

Steps To Reproduce:

1. Have a dirty org with lots of local changes (example, change git branches locally)
2. Run sfdx force:source:tracking:reset
3. respond y
4. Run sfdx force:source:status

Expected result

status to report no changes

Actual result

Huge list of local changes listed

Additional information

SFDX CLI Version(to find the version of the CLI engine run sfdx --version): sfdx-cli/7.65.3-74dd02e949 darwin-x64 node-v10.21.0

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core)
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.0.1 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.7.10 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.0.7 (core)
analytics 1.12.0 (core)
generator 1.1.3 (core)
salesforcedx 48.22.4
├─ salesforcedx-templates 48.18.0
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7
├─ custom-metadata 1.0.4
└─ salesforce-alm 48.24.0
sfdx-cli 7.65.3 (core)

OS and version: macOS 10.15.5

[clairebianchi]

@yippie can you please provide a repo where this is reproducible?

[yippie]

I am having trouble reproducing it in a sample project. Our real project I am not willing to post here but does have 1910 items in it on a fresh push in one folder and 957 in a second. For source organization reasons we are pushing from two different projects to the same org and reset does not seem to ever work on either of them.

[jclark-dot-org]

I am seeing the same in a large project when deleting local files. I just ran a force:source:pull and got a number of unwanted new files, such as WebLinks (no idea why) and QuickActions (that I added in scratch but won't be keeping). I deleted the local changes (git reset) and then tried to reset DX tracking. Other pulled changes (to existing files) were reset, but the deletes all still say "Local Deleted".

Edit to add:

> $ sfdx version       
sfdx-cli/7.68.6-d37008df83 darwin-x64 node-v12.18.3

> $ sfdx plugins --core                                                              
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.0.1 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.7.10 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.0.7 (core)
analytics 1.12.0 (core)
generator 1.1.3 (core)
salesforcedx 49.4.1
├─ custom-metadata 1.0.7
├─ salesforcedx-templates 48.32.0
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7
└─ salesforce-alm 49.4.0
sfdx-cli 7.68.6 (core)
sfpowerkit 2.0.17

Second Edit to add updated to latest cli (49.6.1), issue persists.

[jclark-dot-org]

As a workaround, clearing tracking before resetting seems to fix it. So,

sfdx force:source:tracking:clear
sfdx force:source:tracking:reset

[kevinohara80]

Does anyone know if there is an existing issue logged for the force:source:pull issue where tons of unchanged files get pulled like @jclark-dot-org mentioned? I looked and didn't see one. That is a nasty bug and has caused us a ton of pain over the last month or so.

I think it's a separate issue, but related to this one. We often see this after a fresh push to a new scratch org.

[shetzel]

Following the OP's steps to reproduce using the ebikes-lwc sample repo and about 50 local changes, the reset works as expected. I'd like to help, but without a repro this isn't going to get much traction.

[maaaaarco]

@kevinohara80 @shetzel this seems a duplicate of #572
I've seen this exact same behaviour, running a reset and still the next pull retrieves tons of changes. In our case it's because our repository is rather big (more than 5k components) and the Source Tracking takes a very long time to update all entires in the table. In some rare occasions, more than 10 minutes.
So in our case people were running the reset command too early, before all Source Members were correctly inserted/updated in the system.
I doubt that you can replicate this with a small repo like the _ebikes-lwc_...

[shetzel]

@maaaaarco - thank you. That would definitely cause it. Some of these posts were from before the SourceMember polling was a bit more dialed in. Hopefully it's better now and this is not an issue. You can certainly cause it if you kill the source:push command after the deploy but before the polling is complete, or the polling times out, then run reset and status.

In a future server release(maybe Summer 2021), the command won't need to poll because the SourceMember data will be returned as part of the deploy response. Until then polling is the best option to get the source tracking state correct after a push.

If anyone on this thread feels like this reset command behavior is NOT due to incomplete SourceMember polling after a push, please post with your repro steps.

[yippie]

I have a large repo, in the 3k component range, that reset seems to do nothing. I created a scratch org yesterday morning and did some work in it. This morning I did a reset, waited 10 min, tried to push and still getting conflicts and attempts to delete files as if the reset was never done.

[amphro]

Again, without an example repository and exact repro steps, this isn't going to go anywhere. Closing for now. If anyone provides something more substantial that isn't the case Steve mentioned, then feel free to reopen.