StringIndexOutOfBoundsException in panache when using project and a linebreak before FROM

[Felk]

When executing a Panache query that (a) contains a projection and (b) has a line break before the FROM clause, a StringIndexOutOfBoundsException is thrown:

java.lang.StringIndexOutOfBoundsException: Range [7, -1) out of bounds for length 30
        [...]
        at java.base/java.lang.String.substring(String.java:2715)
        at io.quarkus.hibernate.orm.panache.common.runtime.CommonPanacheQueryImpl.project(CommonPanacheQueryImpl.java:98)
        at io.quarkus.hibernate.orm.panache.runtime.PanacheQueryImpl.project(PanacheQueryImpl.java:33)
        at org.acme.MyEntityRepo.listEverything(MyEntityRepo.java:19)
        [...]
        at org.acme.MyEntityRepoTest_Subclass.testSelect(Unknown Source)
        [...]

I attached a reproducer containing this panache repository:

@ApplicationScoped
@Transactional
public class MyEntityRepo implements PanacheRepository<MyEntity> {
    public List<SomeProjection> listEverything() {
        return find("""
                SELECT e.field
                FROM MyEntity e
                """)
                .project(SomeProjection.class)
                .list();
    }

    @Value
    @RegisterForReflection
    static class SomeProjection {
        String field;
    }
}

quarkus-reproducer-panache-from-linebreak.zip

The issue seems to be in CommonPanacheQueryImpl#L95:

        if (lowerCasedTrimmedQuery.startsWith("select ")) {
            int endSelect = lowerCasedTrimmedQuery.indexOf(" from ");
            String trimmedQuery = query.trim();
            // 7 is the length of "select "
            String selectClause = trimmedQuery.substring(7, endSelect).trim();

Where endSelect is -1 because the from is not necessarily surrounded by spaces in all cases, such as in the reproducer.

[quarkus-bot]

/cc @FroMage, @loicmathieu

[geoand]

@loicmathieu can you think of any reason why #29851 would not work?

I can't say I know much about Panache, but this simple fix seems to make this case work properly

[loicmathieu]

@geoand yes, it should works

[geoand]

Okay, taking it out of draft then