What you see
Running the unit suite prints a ~20-line Pydantic dump:
WARNING intentumdiff.live_server: Invalid edit deltas in request for 'foo.py': 6 validation errors for EditDelta
start_byte
Field required [type=missing, input_value={'invalid_field': True}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.13/v/missing
old_end_byte
Field required [type=missing, input_value={'invalid_field': True}, input_type=dict]
...
...once per missing field, six fields, for a single bad delta.
It is not a bug — the behaviour is right
src/intentumdiff/live_server.py:1229-1234 validates incoming edit deltas and, on failure, logs a warning and continues with edit_deltas = None. That is correct: deltas are optional hints, so a malformed one should degrade to a full re-diff rather than fail the request.
The test at tests/unit/test_live_server.py:552 deliberately sends deltas: [{"invalid_field": True}] and asserts a diff still comes back. So the warning is the test doing its job.
Two things worth fixing anyway
1. The test should assert the warning instead of leaking it
A test that exercises a warning path should capture it, not print it. Using caplog turns 20 lines of noise into an assertion:
def test_invalid_deltas_fall_back_to_full_diff(caplog):
with caplog.at_level(logging.WARNING, logger="intentumdiff.live_server"):
...
assert "Invalid edit deltas" in caplog.textThat is strictly better than silencing it: right now nothing asserts the warning is emitted at all, so the log line could disappear entirely and the test would still pass.
2. The log line is too verbose for a server
str(ValidationError) expands to one stanza per failing field, each with a docs URL. One malformed delta from a misbehaving editor client produces six stanzas; a client sending them per keystroke would flood the log and bury anything real.
Suggested: log the count and the first error, at the same level, with the full detail behind logger.debug. Something like:
Invalid edit deltas for 'foo.py' (6 validation errors, first: start_byte: Field required) - falling back to a full diff
The important information for an operator is "deltas were rejected, a full diff was used". Which six fields were missing is debug detail.
Adding "falling back to a full diff" also makes the log self-explaining: as written, the warning states a problem without saying it was handled, which reads like a failure.
Scope
Small, and not release-blocking. Filed because log noise in a test run is how genuinely important warnings get skimmed past — the same habit that let 0.0.1 ship printing 69 errors per run while exiting 0.
What you see
Running the unit suite prints a ~20-line Pydantic dump:
...once per missing field, six fields, for a single bad delta.
It is not a bug — the behaviour is right
src/intentumdiff/live_server.py:1229-1234validates incoming edit deltas and, on failure, logs a warning and continues withedit_deltas = None. That is correct: deltas are optional hints, so a malformed one should degrade to a full re-diff rather than fail the request.The test at
tests/unit/test_live_server.py:552deliberately sendsdeltas: [{"invalid_field": True}]and asserts a diff still comes back. So the warning is the test doing its job.Two things worth fixing anyway
1. The test should assert the warning instead of leaking it
A test that exercises a warning path should capture it, not print it. Using
caplogturns 20 lines of noise into an assertion:That is strictly better than silencing it: right now nothing asserts the warning is emitted at all, so the log line could disappear entirely and the test would still pass.
2. The log line is too verbose for a server
str(ValidationError)expands to one stanza per failing field, each with a docs URL. One malformed delta from a misbehaving editor client produces six stanzas; a client sending them per keystroke would flood the log and bury anything real.Suggested: log the count and the first error, at the same level, with the full detail behind
logger.debug. Something like:The important information for an operator is "deltas were rejected, a full diff was used". Which six fields were missing is debug detail.
Adding "falling back to a full diff" also makes the log self-explaining: as written, the warning states a problem without saying it was handled, which reads like a failure.
Scope
Small, and not release-blocking. Filed because log noise in a test run is how genuinely important warnings get skimmed past — the same habit that let 0.0.1 ship printing 69 errors per run while exiting 0.