[jira] [Updated] (CAMEL-24131) camel-jpa: consumer with nativeQuery (no resultClass) and default consumeDelete fails to delete rows, causing endless reprocessing

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-24131:
--------------------------------
    Fix Version/s: 4.22.0

> camel-jpa: consumer with nativeQuery (no resultClass) and default consumeDelete fails to delete rows, causing endless reprocessing
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24131
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24131
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-jpa
>            Reporter: Federico Mariani
>            Assignee: Claus Ibsen
>            Priority: Major
>             Fix For: 4.22.0
>
>
> h3. Problem
> When a JPA consumer is configured with {{nativeQuery}} and no {{resultClass}}, results are returned as {{Object[]}} rows (see {{QueryBuilder.nativeQuery(String)}}). {{consumeDelete}} defaults to {{true}}, so {{JpaConsumer.createDeleteHandler()}} (JpaConsumer.java:451-480) returns:
> {code:java}
> (EntityManager em, Object entityBean, Exchange exchange) -> em.remove(entityBean);
> {code}
> {{EntityManager#remove}} requires a managed entity instance; calling it with an {{Object[]}} throws {{IllegalArgumentException}}. Unlike the {{@PreConsumed}}/{{@Consumed}} handlers, which guard with {{entityType.isInstance(entityBean)}} (JpaConsumer.java:435, 463), the {{consumeDelete}} handler has no such guard. {{lockEntity()}} even anticipates this exact case -- it treats a lock failure on an array as expected (JpaConsumer.java:374-376) -- but the delete path does not.
> h3. Impact
> The exchange is processed successfully by the route (the {{Processor.process(exchange)}} call succeeds), but the subsequent {{getDeleteHandler().deleteObject(...)}} call throws. Because this happens *after* successful processing, the row is never deleted from the database. On the next poll, the same native-query result set (same rows) is selected and reprocessed -- a poison-poll loop: duplicate downstream processing plus a logged/thrown error on every single poll, indefinitely.
> h3. How to reproduce
> {code:java}
> from("jpa://com.foo.MyEntity?nativeQuery=select * from MY_ENTITY where processed = false")
>     .to("mock:result");
> {code}
> against a table with at least one matching row and no {{resultClass}} configured: the row is delivered to {{mock:result}} on every poll, and {{em.remove(Object[])}} throws each time.
> h3. Suggested fix
> Guard the default {{consumeDelete}} handler the same way the annotation-based handlers are guarded (e.g. skip/log when the result is not an instance of the configured entity type), or fail endpoint validation eagerly when {{nativeQuery}} is set without {{resultClass}} and {{consumeDelete=true}}.
> Found during a broader camel-jpa code review (July 2026).
> _Claude Code on behalf of Croway_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)