Fix IntCastingNaNError when repairing Volume with NaN in sudden-change ranges

[8910work-cell]

Fixes #2855.

Problem

_fix_prices_sudden_change() rounds and casts corrected Volume values to int in four places. Only the last of the four (at the end of the function) guards against NaN:

if correct_volume:
    f_na = df2['Volume'].isna()
    if f_na.any():
        df2.loc[~f_na,'Volume'] = df2['Volume'][~f_na].round(0).astype('int')
    else:
        df2['Volume'] = df2['Volume'].round(0).astype('int')

The other three call sites do .round().astype('int') directly with no such guard. If a Volume value inside a detected price-repair range (e.g. a bad stock split) is NaN, this raises pandas.errors.IntCastingNaNError: Cannot convert non-finite values (NA or inf) to integer and aborts the whole repair — matching the traceback in #2855.

Fix

(Updated after review — the first iteration kept NaN rows as rounded floats via a helper; per review, Volume is now migrated to nullable Int64 instead.)

At the start of the correction phase in _fix_prices_sudden_change(), the Volume column is converted to pandas nullable Int64. The four correction sites then round and cast their scaled values to Int64, which can hold <NA>, so a NaN inside a repaired range no longer raises. This also makes the NaN special-case at the end of the function unnecessary, so it is removed — a net simplification.

One pandas 3.0 quirk: .iloc-assigning an Int64 Series containing <NA> raises KeyError (pandas positionally indexes the value's own index during setitem validation), so the ranges-loop site assigns the underlying .array — noted in a code comment.

Verification

Reused the checked-in 4063.T bad-stock-split fixture (tests/data/4063-T-1d-bad-stock-split*.csv), which is already known to trigger a Volume-correcting repair range (see TestPriceRepairAssumptions.test_repair_bad_stock_splits). Injecting a NaN into a row inside that corrected range:

• Before this fix: raises IntCastingNaNError (matches the reported bug, confirmed on current dev)
• After this fix: no longer raises; the NaN is preserved as <NA> rather than silently coerced into a wrong integer
• Clean data (no NaN): repair output still matches the existing known-good fixture exactly, and the repaired frame's Volume comes back as Int64 — asserted in the test

Adds two network-free tests to tests/test_price_repair.py (TestFixPricesSuddenChangeVolumeNaN) covering both cases. The bad-stock-split and 100x repair tests in TestPriceRepair still pass.

[ValueRaider]

Maybe switching type to nullable int is better https://pandas.pydata.org/pandas-docs/stable/user_guide/integer_na.html

[8910work-cell]

Agreed that nullable Int64 is the "correct" dtype for a Volume that can be NA, and I looked into it. The blocker is that these are in-place partial assignments into an existing column, e.g.:

df2.loc[f_open_and_closed_fixed, "Volume"] = (df2.loc[f_open_and_closed_fixed, "Volume"] * m_rcp).round().astype('int')

On pandas 3.0, assigning an Int64 series that contains <NA> into a slice of a non-nullable int64/float64 column raises LossySetitemError → TypeError: Invalid value '<NA>' for dtype .... The column has to already be nullable for the partial write to accept NA, so using Int64 here would mean migrating the whole Volume column to Int64 across the repair pipeline — which changes the dtype every downstream consumer of the repaired frame sees. That's a much wider blast radius than this crash fix.

I also kept it consistent with the NaN handling already in this same function a few lines below, which leaves NaN rows as floats rather than casting:

if correct_volume:
    f_na = df2['Volume'].isna()
    if f_na.any():
        df2.loc[~f_na, 'Volume'] = df2['Volume'][~f_na].round(0).astype('int')
    else:
        df2['Volume'] = df2['Volume'].round(0).astype('int')

_round_volume_nansafe does exactly the same thing (int when clean, rounded float when a NaN is present), so the fix stays minimal and local to the crash. Happy to do the full Int64 migration as a separate PR if you'd prefer Volume to become nullable-int project-wide — just let me know which direction you'd like.

[ValueRaider]

migrating the whole Volume column to Int64

Yes. It shouldn't cause any harm.

[8910work-cell]

Done — Volume is now migrated to nullable Int64 at the start of the correction phase in _fix_prices_sudden_change(), so the partial assignments can hold <NA> directly. Net simplification: the _round_volume_nansafe() helper and the NaN special-case at the end of the function are both gone.

One pandas 3.0 quirk hit along the way: .iloc-assigning an Int64 Series containing <NA> raises KeyError (pandas positionally indexes the value's own index during setitem validation), so the ranges-loop site assigns the underlying .array — noted in a code comment.

The regression test now also asserts the repaired frame's Volume comes back as Int64 for clean int64 input. PR description updated to match.

[ValueRaider]

why did you move the if correct_volume: block?