New users - query did not return a uique result

ReportServer (EN)
1

Hello

With the new RS version, we are experiencing issues with newly created users. We tested this both on a fresh installation and on an environment upgraded from the previous version.

After adding a user to the Users group, they are unable to log in. The following error is displayed:

“query did not return a unique result: [record index, if I’m not mistaken]”

Users created before the upgrade can log in without any issues. On a fresh installation, all newly created users exhibit the same behavior.

RS Version: We’ve tested it on 6.1.2 and 6.1.4
RS Edition: CE
Java Version: jdk21
Tomcat Version: 9.0.120
Database version: postgres16
Minimal example/test case for reproduction:

  • Create new RS Instalation with 6.1.2/6.1.4
  • Log as root into RS
  • Create new Folder (let’s named it: “Użytkownicy”)
  • Create a new user in a folder.
  • Add the folder to the Users group in Roles.
  • Log in as the new user (either by using Log As or by logging out and logging back in).

Precondition: PostrgreSQL 16
Complete error messages:
javax.persistence.NonUniqueResultException: query did not return a unique result: 3
at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:128)
at org.hibernate.query.internal.AbstractProducedQuery.getSingleResult(AbstractProducedQuery.java:1672)
at org.hibernate.query.criteria.internal.compile.CriteriaQueryTypeQueryAdapter.getSingleResult(CriteriaQueryTypeQueryAdapter.java:111)
at net.datenwerke.rs.utils.simplequery.byatt.QueryByAttProcessor.process(QueryByAttProcessor.java:120)
at net.datenwerke.rs.utils.simplequery.byatt.QueryByAttInterceptor.invoke(QueryByAttInterceptor.java:24)
at net.datenwerke.rs.dashboard.service.dashboard.DashboardServiceImpl.getDashboardFor(DashboardServiceImpl.java:92)
at net.datenwerke.rs.dashboard.server.dashboard.DashboardRpcServiceImpl.getDashboardForUser(DashboardRpcServiceImpl.java:128)
at com.google.inject.persist.jpa.JpaLocalTxnInterceptor.invoke(JpaLocalTxnInterceptor.java:66)
at net.datenwerke.security.service.security.aop.SecurityCheckInterceptor.invoke(SecurityCheckInterceptor.java:112)
at net.datenwerke.gf.service.gwtstacktrace.CatchStacktraceInterceptor.invoke(CatchStacktraceInterceptor.java:38)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:587)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:333)
at net.datenwerke.security.service.security.aop.SecurityCheckInterceptor.invoke(SecurityCheckInterceptor.java:112)
at net.datenwerke.gf.service.gwtstacktrace.CatchStacktraceInterceptor.invoke(CatchStacktraceInterceptor.java:38)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:303)
at net.datenwerke.security.service.security.aop.SecurityCheckInterceptor.invoke(SecurityCheckInterceptor.java:112)
at net.datenwerke.gf.service.gwtstacktrace.CatchStacktraceInterceptor.invoke(CatchStacktraceInterceptor.java:38)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:373)
at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:555)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:623)
at net.datenwerke.security.service.security.aop.SecurityCheckInterceptor.invoke(SecurityCheckInterceptor.java:112)
at net.datenwerke.gf.service.gwtstacktrace.CatchStacktraceInterceptor.invoke(CatchStacktraceInterceptor.java:38)
at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:293)
at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:283)
at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:184)
at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:89)
at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:85)
at com.google.inject.persist.PersistFilter.doFilter(PersistFilter.java:94)
at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:121)
at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:133)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:170)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:146)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:166)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:88)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:534)
at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:803)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:129)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:86)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:764)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:71)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:350)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:407)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:71)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:1344)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:2089)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:74)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:976)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:494)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:80)
at java.base/java.lang.Thread.run(Thread.java:1583)

In database we can observe such error too:
Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; statement executed: update RS_USERMANAGER_NODE set created_on=?, flags=?, last_updated=?, parent_id=?, position=?, entity_version=?, acl_id=?, owner_id=?, guid=?, origin=? where entity_id=? and entity_version=?

2

Hello Reedu,

Thank you for your message. We have received your request and are currently investigating the issue. We will get back to you as soon as we have an update.

Kind regards,
Jasmin

3

Hello Reedu,

Unfortunately, our developers were unable to reproduce the issue you reported. As the problem cannot currently be reproduced, we are unable to continue our investigation at this time and will close this case for now.

If you are able to provide any additional information that would help us reproduce the issue, please do not hesitate to contact us at any time .

Thank you for your understanding.

Kind regards,
Jasmin

1 Like
4

We did some additional investigation and found a reproducible scenario.

When a newly created user logs in normally (logout from root and login using username/password), everything works correctly and no exception is thrown.

However, when a newly created user is accessed BEFORE he/she logs in, using “Switch user” from the root account, the problem appears.
For affected users, multiple records are created in RS_DASHBOARD_USER for the same user_id.
The query “select * from rs_dashboard_user where user_id = <new_user_id>;”
returns multiple rows with different dashboard_container_id values.

Observed counts:

  • 2 records
  • 3 records
  • 4 records
  • 5 records
    for a single user.

Interestingly, the number is not constant and seems to vary between attempts.

When the same type of user logs in using the normal login page (without using “Swtich user”), only a single RS_DASHBOARD_USER record is created and the login succeeds.

The issue appears to be specifically related to the user switching.

The exception is sometimes raised with a lower number than the final amount of rows visible in the database afterwards.
For example: query did not return a unique result: 3
but after the operation completes there may already be 4 rows for that same user in RS_DASHBOARD_USER.

This suggests that additional inserts may still be occurring after the first failing query has already been executed.

Workaround
If all extra records are removed manually and only a single row is left in RS_DASHBOARD_USER for the affected user, the user can log in successfully.

5

@IF_Jasmin does this information help you somehow?

6

Hello Reedu,

Please accept our apologies for the delay.

Due to limited capacity, our development team has unfortunately not yet been able to continue working on your ticket. Based on the current status, however, your issue is expected to be addressed within the next few days .

I will get back to you as soon as I receive an update from our developers and keep you informed of any progres s.

Thank you for your understanding and patien ce.

Kind regards,

Jasmin

7

Hello Reedu,

unfortunately, despite the information you provided, our development team has still been unable to reproduce the issue you reported.

For this reason, we have temporarily suspended further investigation of the issue.

Should any new information or findings become available in the future, we will of course review the matter again.

Thank you for your understanding.

Kind regards,

Susanne