Entity Framework updating working set when there are no changes

[macneale4]

A user demonstrated unusual behavior as the following:

With a repository that has no local changes at all, there is a code path which performs the following SQL:

call dolt_commit("-Am", "msg");

And an error is returned which says "nothing to commit". When they attempt to pull there is a message stating that there are uncommited changes.

Looking at their repository, the working set root doesn't match HEAD, so there is something which is updating DB state when it shouldn't be.

To make matters more interesting, if the break that call into two operations:

call dolt_add("."); call dolt_commit("-m", "msg")

They get the same error, but the working set is not altered. So this gets the user around the issue for the time being.

But doing this manually via dolt sql, there is no update to the working set, so it's still not clear how the repository is getting into this state.

FWIW, the IDs of the roots are in fact different, but as far as I can tell the contents is identical.

[macneale4]

Details from the data. TL;DR; it looks like two identical root objects are getting different addresses.

StoreRoot -
1)       { key: refs/heads/main ref: #ekor6d98kp6uvvogotn4ai0glhseqnvr }
2)       { key: refs/internal/create ref: #q4d7nai4mksu1qdgm6mp2iv1drj474it }
3)       { key: refs/remotes/origin/main ref: #idvveje06ngn4cipdvfst4mq37o5riga }
4)       { key: workingSets/heads/main ref: #qr253iljibq6voj6sesal7knva0j874f }

refs/head/main root value: 2ot34duv6360tm036o44a2ecv977p26l

workingSets/heads/main StagedRootAddr: 2ot34duv6360tm036o44a2ecv977p26l (Same, nothing added) workingSets/heads/main WorkingRootAddr: njo8qdp36gmmrru95ro0qs97774ok94o (different, even though nothing was added) - this is why we think there are uncommitted changes!

If we look at the content for each root, they appear to be identical:

njo8qdp36gmmrru95ro0qs97774ok94o

     RootValue - {
        FeatureVersion: 7
1)      ForeignKeys: #21iktsueoaqodo072j5qd1k9boh0iule
        Tables: AddressMap {
2)              AddressContainer: #e60qptioc0na4s4md6bn5kh0pgh653rg
3)              AnalogAddressBlock: #kmfbfav6i8r97jof5fpso1c32mms49ed
4)              AnalogSignal: #16bv3lq6k6jv01ftlt5gvbh41bhhenav
5)              Area: #h662665btmga4t5ke3rhht00ct03fq6b
6)              AreaPlc: #nfmta19m37qbhb0j92k5c46l6duor3pt
7)              BranchUsers: #2bhl2ihneihhr6e68io7r5gfn7uj7ufc
8)              Cabinet: #iek36gqmuhq474c76s8c822tfqiovqfc
9)              CatalogAddressBlock: #5sovicnj94d8utpaji1lg5e0hr7cg9f9
10)             CatalogAddressContainer: #a8re0hdn964rlc762fri0nh49p2nrf3l
11)             CatalogContainerBlock: #4j058f831ue36r01dddci449elkp5c6h
12)             DigitalAddressBlock: #t93c54argrq48n63tn4r706ops8e2t1g
13)             DigitalSignal: #ninhd02bffks0k040aaugdo25752pn8c
14)             Enterprise: #c92slfd2tdsbev3gcqfio44sj162ihp8
15)             Equipment: #93sgnvaspmp1cc1juc530g6tetffprvv
16)             EquipmentAtributeAnalogSignal: #0088somn9v5ksl7vg9m8vr8367o096fr
17)             EquipmentAtributeDecimal: #7ear0h474krqqu6ucgtba1fk4tadm2hr
18)             EquipmentAtributeDigitalSignal: #jntr9b4uq4t7h32q8opbcfr5l0u8m1ti
19)             EquipmentAtributeInt: #5t78kd0ojjv7s6m1cb6mkfnfogu1ievg
20)             EquipmentAtributeString: #oq265p9jeglasthhk8i7c06fjmen5rs6
21)             EquipmentType: #2t2k00g8rrvgqmo7bm613432us24csgk
22)             EquipmentTypeAtributeAnalogSignal: #rpr6gmq5e19f75q26uuk5j8rqsf8r5vo
23)             EquipmentTypeAtributeDecimal: #5io44apu6q5q0glm5p4fihrgb5mqbn93
24)             EquipmentTypeAtributeDigitalSignal: #0t7g8eqfsrgddcu8bbrecs74klgdbrni
25)             EquipmentTypeAtributeInt: #q4alck0k3hqu5oqgsonno2mhpe5at1nv
26)             EquipmentTypeAtributeString: #7rfdmqqjpqnhtggnfu8s1143142v6lms
27)             EquipmentTypeAtributeType: #kf22veg1upr96s966tlmoutap0vnee00
28)             GeneralEquipmentType: #n2q15hjlkbv0umqe9trqddsq5cnjj5u6
29)             MainEquipmentType: #jmhigethvobb7rjnt6mfe6siei7ftvt5
30)             OrderHistory: #94f1j7ssmar5v7mrm9c21ibecgk7221o
31)             Plc: #8j9m8dphjp815trkvnmsrtk2ldoamivk
32)             Room: #b4blklsi3tm6c9547clm42jg66kobbmd
33)             Unit: #kl7jioga8scjm58qpidbtivtbnafr14s
34)             __EFMigrationsHistory: #u38ml0m4409oepqea1a8kbgttihkrmvd
        }
     }

2ot34duv6360tm036o44a2ecv977p26l

     RootValue - {
        FeatureVersion: 7
1)      ForeignKeys: #21iktsueoaqodo072j5qd1k9boh0iule
        Tables: AddressMap {
2)              AddressContainer: #e60qptioc0na4s4md6bn5kh0pgh653rg
3)              AnalogAddressBlock: #kmfbfav6i8r97jof5fpso1c32mms49ed
4)              AnalogSignal: #16bv3lq6k6jv01ftlt5gvbh41bhhenav
5)              Area: #h662665btmga4t5ke3rhht00ct03fq6b
6)              AreaPlc: #nfmta19m37qbhb0j92k5c46l6duor3pt
7)              BranchUsers: #2bhl2ihneihhr6e68io7r5gfn7uj7ufc
8)              Cabinet: #iek36gqmuhq474c76s8c822tfqiovqfc
9)              CatalogAddressBlock: #5sovicnj94d8utpaji1lg5e0hr7cg9f9
10)             CatalogAddressContainer: #a8re0hdn964rlc762fri0nh49p2nrf3l
11)             CatalogContainerBlock: #4j058f831ue36r01dddci449elkp5c6h
12)             DigitalAddressBlock: #t93c54argrq48n63tn4r706ops8e2t1g
13)             DigitalSignal: #ninhd02bffks0k040aaugdo25752pn8c
14)             Enterprise: #c92slfd2tdsbev3gcqfio44sj162ihp8
15)             Equipment: #93sgnvaspmp1cc1juc530g6tetffprvv
16)             EquipmentAtributeAnalogSignal: #0088somn9v5ksl7vg9m8vr8367o096fr
17)             EquipmentAtributeDecimal: #7ear0h474krqqu6ucgtba1fk4tadm2hr
18)             EquipmentAtributeDigitalSignal: #jntr9b4uq4t7h32q8opbcfr5l0u8m1ti
19)             EquipmentAtributeInt: #5t78kd0ojjv7s6m1cb6mkfnfogu1ievg
20)             EquipmentAtributeString: #oq265p9jeglasthhk8i7c06fjmen5rs6
21)             EquipmentType: #2t2k00g8rrvgqmo7bm613432us24csgk
22)             EquipmentTypeAtributeAnalogSignal: #rpr6gmq5e19f75q26uuk5j8rqsf8r5vo
23)             EquipmentTypeAtributeDecimal: #5io44apu6q5q0glm5p4fihrgb5mqbn93
24)             EquipmentTypeAtributeDigitalSignal: #0t7g8eqfsrgddcu8bbrecs74klgdbrni
25)             EquipmentTypeAtributeInt: #q4alck0k3hqu5oqgsonno2mhpe5at1nv
26)             EquipmentTypeAtributeString: #7rfdmqqjpqnhtggnfu8s1143142v6lms
27)             EquipmentTypeAtributeType: #kf22veg1upr96s966tlmoutap0vnee00
28)             GeneralEquipmentType: #n2q15hjlkbv0umqe9trqddsq5cnjj5u6
29)             MainEquipmentType: #jmhigethvobb7rjnt6mfe6siei7ftvt5
30)             OrderHistory: #94f1j7ssmar5v7mrm9c21ibecgk7221o
31)             Plc: #8j9m8dphjp815trkvnmsrtk2ldoamivk
32)             Room: #b4blklsi3tm6c9547clm42jg66kobbmd
33)             Unit: #kl7jioga8scjm58qpidbtivtbnafr14s
34)             __EFMigrationsHistory: #u38ml0m4409oepqea1a8kbgttihkrmvd
        }
     }

[macneale4]

Looking at the raw data in the two chunks mentioned in the previous comment, we believe the collation if the database has been changed. This information is not currently used when printing the status, which lines up with what the user is seeing.

[jycor]

We've added a way to deal with database collation changes, describe here: https://github.com/dolthub/dolt/issues/7815#issuecomment-2105274869