What causes "Failed to re-invoke operation after successful login" in pentaho/pentaho-kettle?

Inspect getCause() for the underlying failure from the re-invoked operation

pentaho/pentaho-kettle · error · LoginSuccessReinvokeException

Failed to re-invoke operation after successful login

Error message

Failed to re-invoke operation after successful login

What it means

SessionTimeoutHandler.handleLoginSuccess, after a successful re-login triggered by a session timeout, re-invokes the original operation reflectively. If that re-invocation throws InvocationTargetException, it wraps the cause in LoginSuccessReinvokeException('Failed to re-invoke operation after successful login'). Login worked, but executing the original work after re-login failed.

Solutions

Inspect getCause() for the underlying failure from the re-invoked operation
Confirm the re-login used an account with the same permissions as before
Re-navigate/refresh the repository browser and redo the action manually
Check server logs for the underlying exception raised during the retry

Example fix

// before
handler.performLoginAndReinvoke(...); // opaque failure
// after
try {
  handler.performLoginAndReinvoke(...);
} catch ( LoginSuccessReinvokeException e ) {
  log.error( "Operation failed after re-login:", e.getCause() );
}

Defensive patterns

Strategy: retry

Validate before calling

// confirm equivalent permissions after re-login
if ( !repository.hasAccess( path, RepositoryPermission.PERMISSION_MANAGE_ACCESS ) ) {
  throw new SecurityException( "Re-logged user lacks prior permissions" );
}

Try / catch

try {
  handler.performLoginAndReinvoke( objectToHandle, method, args );
} catch ( LoginSuccessReinvokeException e ) {
  log.error( "Post-login re-invocation failed:", e.getCause() );
  // offer manual retry in UI
}

Prevention

Re-login with the same account that owned the original session
Make deferred operations idempotent and re-validate preconditions before the retry
Read getCause() for the real server-side failure
Refresh repository browser state after re-login before retrying UI actions

When it happens

Trigger: User re-logs in after a timeout; the deferred method invocation throws any exception (server-side failure, missing file, permission change in the new session).

Common situations: The newly logged-in user lacks permission the old session had; repository state changed while disconnected; the retried operation hits a server error.

Related errors

AI-assisted analysis of pentaho/pentaho-kettle@f3058517a1 (2026-09-13). Data as JSON: /api/errors/72c3488c8353c79c. Report an issue: GitHub.

Appendix: source

Thrown at plugins/repositories/core/src/main/java/org/pentaho/di/ui/repo/timeout/SessionTimeoutHandler.java:166

        return new ReinvokeResult( handleLoginSuccess( objectToHandle, method, args ) );
      } else {
        handleLoginCanceled();
      }
    }
    return null;
  }

  /**
   * Called after the user successfully logs in. Initializes repository providers and
   * re-invokes the original method.
   */
  private Object handleLoginSuccess( Object objectToHandle, Method method, Object[] args )
      throws LoginSuccessReinvokeException {
    initializeRepositoryProvidersAfterReconnection( getSpoon() );
    try {
      return method.invoke( objectToHandle, args );
    } catch ( InvocationTargetException ex ) {
      throw new LoginSuccessReinvokeException( "Failed to re-invoke operation after successful login",
          ex.getCause() );
    } catch ( IllegalAccessException | IllegalArgumentException ex ) {
      throw new LoginSuccessReinvokeException( "Unable to invoke operation after successful login", ex );
    }
  }

  static class LoginSuccessReinvokeException extends KettleException {
    private static final long serialVersionUID = 1L;

    LoginSuccessReinvokeException( String message, Throwable cause ) {
      super( message, cause );
    }
  }

  /**
   * Wrapper that distinguishes "reinvocation happened and returned a value (possibly null)"
   * from "no reinvocation was performed".  Using a plain {@code Object} return would conflate
   * a legitimate {@code null} return value with "nothing happened".

View on GitHub (pinned to f3058517a1)