backtrace when writing different integer schema about influxdb HOT 4 CLOSED

@hiltontj the write should never have gotten to that point. It should have failed validation and returned an error to the user. That function should only get called after successful validation.

from influxdb.

The function that is issuing the first panic (unexpected field type) is here:

add_rows is infallible, which will need to change in order to respond with an error in the API response and to prevent the wal op buffer thread from dying; unless we can validate the data types upstream and respond with error from there.

from influxdb.

Fyi, Clustered (and presumably Dedicated) handles this fine:

$ curl -H "Authorization: Basic $V1AUTH" -X POST "$URL/write?db=test&precision=s" --data-binary @./i.lp
$ curl -H "Authorization: Basic $V1AUTH" -X POST "$URL/write?db=test&precision=s" --data-binary @./u.lp
{"code":"invalid","message":"dml handler error: schema conflict: table t0, already exists: column t0_f0 is type i64 but schema update has type u64"}

from influxdb.

I have a reproducer up in #25022

from influxdb.