Database New Added 8 September 2026

Elasticsearch: mapper_parsing_exception, failed to parse field

A document's value does not fit the field's mapped type. Dynamic mapping fixes a type from the first document it sees, so an id that arrived as a number becomes a long and every later string id is rejected. Mappings cannot be changed in place.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

# What is the field mapped as?
curl -s 'localhost:9200/orders/_mapping?pretty' | jq '.orders.mappings.properties.id'

# Fix by reindexing into a corrected mapping
curl -X PUT localhost:9200/orders-v2 -H 'Content-Type: application/json' -d '{
  "mappings": { "properties": { "id": { "type": "keyword" } } } }'
curl -X POST localhost:9200/_reindex -H 'Content-Type: application/json' -d '{
  "source": {"index": "orders"}, "dest": {"index": "orders-v2"} }'

# Then move the alias so clients do not change
curl -X POST localhost:9200/_aliases -d '{"actions":[
  {"remove":{"index":"orders","alias":"orders-read"}},
  {"add":{"index":"orders-v2","alias":"orders-read"}}]}'

# Prevent the next one: define mappings up front with an index template

How to diagnose Database errors

Database errors group into connection exhaustion, lock contention and deadlocks, constraint violations, and resource limits. Connection errors under load are the most misdiagnosed: "too many connections" is almost never fixed by raising max_connections, because each connection costs memory. It is fixed by putting a pooler in front and finding the code path that leaks connections.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Look at what the server currently sees: SELECT * FROM pg_stat_activity in PostgreSQL, SHOW FULL PROCESSLIST in MySQL. Sessions sitting in idle in transaction are the usual culprit behind connection exhaustion.
For deadlocks, read the deadlock report the database logs. It names both transactions and the exact lock order. The fix is nearly always to make all code paths acquire locks in the same order.
Check whether the error is from the database or from a pooler. PgBouncer, ProxySQL and RDS Proxy return their own errors that look database-native but need pooler-side fixes.
Run EXPLAIN (ANALYZE, BUFFERS) on slow queries. Lock-wait timeouts are often just very slow queries holding locks longer than they should.
Verify you are connected to the writer, not a read replica. READONLY and "cannot execute in a read-only transaction" errors mean traffic is reaching the wrong endpoint.

Tools worth reaching for

pg_stat_activity
SHOW ENGINE INNODB STATUS
EXPLAIN ANALYZE
slow query log
pgbadger

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

elastic.co

Related Database errors

See all 41 Database errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.