Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] If an exception occurs while sending an Azure storage request and it doesn't have a cause then the information in the exception gets dropped #43463

Open
1 task done
charlesjmorgan opened this issue Dec 18, 2024 · 0 comments
Labels
customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that

Comments

@charlesjmorgan
Copy link

Describe the bug
The error handling for the sendRequest method in the StorageImplUtils assumes that the exception has a cause:

Throwable cause = e.getCause();
if (exceptionType.isInstance(e)) {
// Safe to cast since we checked with isInstance
throw exceptionType.cast(e);
} else if (cause instanceof RuntimeException) {
// Throw as is if it's already a RuntimeException
throw (RuntimeException) cause;
} else if (cause instanceof Error) {
// Propagate if it's an Error
throw (Error) cause;
} else {
// Wrap in RuntimeException if it's neither Error nor RuntimeException
throw LOGGER.logExceptionAsError(new RuntimeException(cause));
}
If the exception doesn't have a cause and it is the root cause itself then any information contained in the caught exception is dropped and a generic RuntimeException is thrown with a null cause

Exception or Stack Trace
Just an empty RuntimeException that gets thrown without a cause from StorageImplUtils#sendRequest

To Reproduce
Steps to reproduce the behavior: I don't believe these are needed

Code Snippet

    public static <T> T sendRequest(Callable<T> operation, Duration timeout,
        Class<? extends RuntimeException> exceptionType) {
        try {
            if (timeout == null) {
                return operation.call();
            }
            Future<T> future = SharedExecutorService.getInstance().submit(operation);
            return getResultWithTimeout(future, timeout.toMillis(), exceptionType);
        } catch (Exception e) {
            Throwable cause = e.getCause();
            if (exceptionType.isInstance(e)) {
                // Safe to cast since we checked with isInstance
                throw exceptionType.cast(e);
            } else if (cause instanceof RuntimeException) {
                // Throw as is if it's already a RuntimeException
                throw (RuntimeException) cause;
            } else if (cause instanceof Error) {
                // Propagate if it's an Error
                throw (Error) cause;
            } else {
                // Wrap in RuntimeException if it's neither Error nor RuntimeException
                throw LOGGER.logExceptionAsError(new RuntimeException(cause));
            }
        }
    }

Expected behavior
I expect that if an exception is caught in the sendRequest method and it doesn't have a cause that the same exception should be rethrown if it is either a runtime exception or an error.

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

  • Bug Description Added
  • [/] Repro Steps Added
  • [/] Setup information Added
@github-actions github-actions bot added customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that
Projects
None yet
Development

No branches or pull requests

1 participant