BUG: inconsistent `groupby.apply` behaviour depending on column dtypes

[od-crypto]

I see strange groupby.apply behaviour: resulting index depends on the existence of the Timestamp dtype column. MWE:

import pandas as pd
df = pd.DataFrame({
    'date_val': {
        0: pd.Timestamp('2017-01-01 00:00:00'),
        1: pd.Timestamp('2017-01-01 00:00:00'),
        2: pd.Timestamp('2017-02-01 00:00:00'),
        3: pd.Timestamp('2017-02-01 00:00:00')
    },
    'uid': {
        0: '1',
        1: '2',
        2: '1',
        3: '2'
    },
    'str_val': {
        0: str('2017-01-01 00:00:00'),
        1: str('2017-01-01 00:00:00'),
        2: str('2017-02-01 00:00:00'),
        3: str('2017-02-01 00:00:00')
    }
})

df1 = df.groupby('uid', as_index=False)[['uid', 'str_val', 'date_val']].apply(lambda x: x.sort_values(by='str_val',ascending=True))
df2 = df.groupby('uid', as_index=False)[['uid', 'str_val']].apply(lambda x: x.sort_values(by='str_val',ascending=True))
df3 = df.groupby('uid', as_index=False)[['uid', 'date_val']].apply(lambda x: x.sort_values(by='date_val',ascending=True))

print(df1)
print(df2)
print(df3)

Output:

  uid              str_val   date_val
0   1  2017-01-01 00:00:00 2017-01-01
1   2  2017-01-01 00:00:00 2017-01-01
2   1  2017-02-01 00:00:00 2017-02-01
3   2  2017-02-01 00:00:00 2017-02-01
    uid              str_val
0 0   1  2017-01-01 00:00:00
  2   1  2017-02-01 00:00:00
1 1   2  2017-01-01 00:00:00
  3   2  2017-02-01 00:00:00
  uid   date_val
0   1 2017-01-01
1   2 2017-01-01
2   1 2017-02-01
3   2 2017-02-01

I expect the index to be like in the second output (df2). Indexes in df1 and df3 seem strange.

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 5f648bf
python : 3.8.0.final.0
python-bits : 64
OS : Darwin
OS-release : 18.7.0
Version : Darwin Kernel Version 18.7.0: Mon Apr 27 20:09:39 PDT 2020; root:xnu-4903.278.35~1/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8

pandas : 1.3.2
numpy : 1.21.2
pytz : 2021.1
dateutil : 2.8.2
pip : 21.2.2
setuptools : 52.0.0.post20210125
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.0.1
IPython : 7.26.0
pandas_datareader: None
bs4 : None
bottleneck : None
fsspec : None
fastparquet : None
gcsfs : None
matplotlib : 3.4.3
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyxlsb : None
s3fs : None
scipy : 1.7.1
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : None

[simonjayhawkins]

Thanks @od-crypto for the report.

I expect the index to be like in the second output (df2). Indexes in df1 and df3 seem strange.

That was the result on 1.2.5

On master the second case now has the same index as the other two cases, a regular index.

not sure without investigating further which is correct or whether the changes were intentional.

will label as a regression for now pending further investigation.

[simonjayhawkins]

not sure without investigating further which is correct or whether the changes were intentional.

for 1st case

first bad commit: [a3bb751] REF: back DatetimeBlock, TimedeltaBlock by DTA/TDA (#40456)

so the change was probably not intentional. @jbrockmendel is #42921 (comment) relevant here?

[simonjayhawkins]

On master the second case now has the same index as the other two cases, a regular index.

first bad commit: [d037ff6] REF: remove libreduction.apply_frame_axis0 (#42992)

as this is a very recent change, could considered reverting that.

[jbrockmendel]

Looks like this is driven by a difference in the cython vs python code paths, likely involving how mutated is set.

[jbrockmendel]

Porting the mutation check from the now-deleted apply_frame_axis_0 into BaseGrouper.apply seems to fix this. need to run the rest of the tests