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

add runnable/callable class in async invoke method #1327

Merged
merged 1 commit into from
May 28, 2024

Conversation

HzjNeverStop
Copy link
Contributor

@HzjNeverStop HzjNeverStop commented May 27, 2024

Summary by CodeRabbit

  • New Features

    • Enhanced asynchronous health check processing for improved performance and reliability.
  • Refactor

    • Improved code readability and maintainability by refactoring methods to use new classes for asynchronous operations.

Copy link

coderabbitai bot commented May 27, 2024

Walkthrough

The recent updates to the SOFA Boot project enhance asynchronous processing across various components. Key changes include the introduction of Runnable and Callable classes to handle health checks and context refreshes asynchronously, improving code readability and maintainability. These modifications aim to optimize the performance and efficiency of asynchronous tasks within the project.

Changes

File Path Change Summary
.../sofa-boot-actuator/.../HealthCheckerProcessor.java Introduced AsyncHealthCheckRunnable and AsyncHealthCheckCallable for better asynchronous health checks.
.../sofa-boot-actuator/.../HealthIndicatorProcessor.java Added AsyncHealthIndicatorRunnable and AsyncHealthIndicatorCallable to enhance asynchronous health check processing.
.../sofa-boot-core/isle-sofa-boot/.../SpringContextInstallStage.java Refactored refreshRecursively to use AsyncSpringContextRunnable for improved code readability and maintainability.
.../sofa-boot-core/runtime-sofa-boot/.../AsyncInitializeBeanMethodInvoker.java Refactored invoke method to use AsyncBeanInitRunnable for better organization and readability of asynchronous method invocation logic.

Poem

In fields of code where rabbits roam,
Asynchronous tasks now call their home.
With Runnables and Callables in play,
The health checks dance in a smoother way.
Contexts refresh with nimble speed,
A coder's dream, indeed, indeed!
🐇✨


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to full the review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 6

Outside diff range and nitpick comments (1)
sofa-boot-project/sofa-boot-core/isle-sofa-boot/src/main/java/com/alipay/sofa/boot/isle/stage/SpringContextInstallStage.java (1)

187-192: The implementation of asynchronous context refresh using AsyncSpringContextRunnable is a good approach to parallelize operations. Ensure that the executor service is properly managed to avoid resource leaks.

Consider monitoring the executor service's health and shutdown behavior to ensure that threads are not left hanging after operations complete.

Review Details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits Files that changed from the base of the PR and between c743030 and 083cd71.
Files selected for processing (4)
  • sofa-boot-project/sofa-boot-actuator/src/main/java/com/alipay/sofa/boot/actuator/health/HealthCheckerProcessor.java (7 hunks)
  • sofa-boot-project/sofa-boot-actuator/src/main/java/com/alipay/sofa/boot/actuator/health/HealthIndicatorProcessor.java (4 hunks)
  • sofa-boot-project/sofa-boot-core/isle-sofa-boot/src/main/java/com/alipay/sofa/boot/isle/stage/SpringContextInstallStage.java (2 hunks)
  • sofa-boot-project/sofa-boot-core/runtime-sofa-boot/src/main/java/com/alipay/sofa/runtime/async/AsyncInitializeBeanMethodInvoker.java (2 hunks)
Additional comments not posted (2)
sofa-boot-project/sofa-boot-actuator/src/main/java/com/alipay/sofa/boot/actuator/health/HealthIndicatorProcessor.java (1)

219-219: Ensure that the callable for health checks properly handles exceptions and consider adding specific exception handling for known error conditions.

Verification successful

The AsyncHealthIndicatorCallable class within the HealthIndicatorProcessor.java file does not have any specific exception handling within its call method. However, the submit method in the HealthIndicatorProcessor class does handle exceptions, including TimeoutException and general Exception.

  • The call method in AsyncHealthIndicatorCallable simply calls healthIndicator.health() and throws any exceptions that occur.
  • The submit method in HealthIndicatorProcessor catches TimeoutException and general Exception, logging errors and setting the health status accordingly.

This indicates that while the AsyncHealthIndicatorCallable itself does not handle exceptions, the submit method that uses it does handle exceptions appropriately.

  • AsyncHealthIndicatorCallable class:

    private class AsyncHealthIndicatorCallable implements Callable<Health> {
        private final HealthIndicator healthIndicator;
    
        public AsyncHealthIndicatorCallable(HealthIndicator healthIndicator) {
            this.healthIndicator = healthIndicator;
        }
    
        @Override
        public Health call() throws Exception {
            return healthIndicator.health();
        }
    }
  • submit method in HealthIndicatorProcessor:

    try {
        if (wait) {
            Future<Health> future = healthCheckExecutor
                    .submit(new AsyncHealthIndicatorCallable(healthIndicator));
            health = future.get(timeout, TimeUnit.MILLISECONDS);
        } else {
            health = healthIndicator.health();
        }
        Status status = health.getStatus();
        result = status.equals(Status.UP);
        if (!result) {
            logger.error(
                    ErrorCode.convert("01-21001",
                            beanId, status, objectMapper.writeValueAsString(health.getDetails())));
        }
    } catch (TimeoutException e) {
        result = false;
        logger.error(
                "HealthIndicator[{}] readiness check fail; the status is: {}; the detail is: timeout, the timeout value is: {}ms.",
                beanId, Status.UNKNOWN, timeout);
        health = new Health.Builder().withException(e).withDetail("timeout", timeout).status(Status.UNKNOWN).build();
    } catch (Exception e) {
        result = false;
        logger.error(

The exception handling in the submit method appears to be comprehensive, covering both specific and general exceptions.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that all possible exceptions in health checks are handled.
# Test: Search for exception handling patterns in health check callables.
rg --type java 'call.*catch' --context 5

Length of output: 42



Script:

#!/bin/bash
# Locate the definition of AsyncHealthIndicatorCallable
ast-grep --lang java --pattern 'class AsyncHealthIndicatorCallable { $$$ }'

# Search for exception handling within the AsyncHealthIndicatorCallable class
rg --type java 'AsyncHealthIndicatorCallable' --context 10 | rg 'catch'

# Search for exception handling within the HealthIndicatorProcessor class
rg --type java 'HealthIndicatorProcessor' --context 10 | rg 'catch'

Length of output: 367



Script:

#!/bin/bash
# Locate the definition of AsyncHealthIndicatorCallable more precisely
rg --files-with-matches 'class AsyncHealthIndicatorCallable' --type java

# Search for exception handling within the AsyncHealthIndicatorCallable class
rg 'class AsyncHealthIndicatorCallable' --type java --context 10 | rg 'catch'

# Search for exception handling within the HealthIndicatorProcessor class
rg 'class HealthIndicatorProcessor' --type java --context 10 | rg 'catch'

Length of output: 344



Script:

#!/bin/bash
# Extract the AsyncHealthIndicatorCallable class definition from HealthIndicatorProcessor.java
rg 'class AsyncHealthIndicatorCallable' -A 50 sofa-boot-project/sofa-boot-actuator/src/main/java/com/alipay/sofa/boot/actuator/health/HealthIndicatorProcessor.java

# Extract the submit method and its surrounding context from HealthIndicatorProcessor.java
rg 'submit' -A 20 -B 10 sofa-boot-project/sofa-boot-actuator/src/main/java/com/alipay/sofa/boot/actuator/health/HealthIndicatorProcessor.java

Length of output: 2145

sofa-boot-project/sofa-boot-actuator/src/main/java/com/alipay/sofa/boot/actuator/health/HealthCheckerProcessor.java (1)

173-173: Ensure that the callable for health checks properly handles exceptions and consider adding specific exception handling for known error conditions.

Verification successful

The callables AsyncHealthIndicatorCallable and AsyncHealthCheckCallable do not appear to have specific exception handling within their call methods. The exception handling is done outside these callables, in the methods that submit these callables to the executor.

  • AsyncHealthIndicatorCallable simply calls healthIndicator.health() and throws any exceptions that occur.
  • AsyncHealthCheckCallable calls healthChecker.isHealthy() and throws any exceptions that occur.

The exception handling for these callables is managed in the surrounding code where they are submitted to the executor and where the results are processed.

These files contain the logic to handle exceptions such as TimeoutException and other general exceptions, logging errors, and updating health statuses accordingly.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that all possible exceptions in health checks are handled.
# Test: Search for exception handling patterns in health check callables.
rg --type java 'call.*catch' --context 5

Length of output: 42



Script:

#!/bin/bash
# Description: Identify the callable used for health checks and check for exception handling.
# Step 1: Find the definition of the callable used in health checks.
rg --type java 'Callable<Health>' --context 5

# Step 2: Check for exception handling within the identified callable.
# This will be done after identifying the callable.

Length of output: 3284



Script:

#!/bin/bash
# Description: Check for exception handling within the identified callables.
# Step 1: Search for exception handling within AsyncHealthIndicatorCallable.
rg --type java 'AsyncHealthIndicatorCallable' --context 10

# Step 2: Search for exception handling within AsyncHealthCheckCallable.
rg --type java 'AsyncHealthCheckCallable' --context 10

Length of output: 14051

Comment on lines +85 to +86
LOGGER.info("{}({}) {} method wait {}ms.", targetObject.getClass().getName(), beanName,
methodName, (System.currentTimeMillis() - startTime));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding more detailed logging for the wait duration to aid in debugging and performance monitoring.

- LOGGER.info("{}({}) {} method wait {}ms.", targetObject.getClass().getName(), beanName, methodName, (System.currentTimeMillis() - startTime));
+ LOGGER.debug("Waiting for async method completion. Class: {}, Bean: {}, Method: {}, Wait Time: {}ms.", targetObject.getClass().getName(), beanName, methodName, (System.currentTimeMillis() - startTime));

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change
LOGGER.info("{}({}) {} method wait {}ms.", targetObject.getClass().getName(), beanName,
methodName, (System.currentTimeMillis() - startTime));
LOGGER.debug("Waiting for async method completion. Class: {}, Bean: {}, Method: {}, Wait Time: {}ms.", targetObject.getClass().getName(), beanName, methodName, (System.currentTimeMillis() - startTime));

Comment on lines +96 to +118
private class AsyncBeanInitRunnable implements Runnable {

private final MethodInvocation invocation;

public AsyncBeanInitRunnable(MethodInvocation invocation) {
this.invocation = invocation;
}

@Override
public void run() {
try {
long startTime = System.currentTimeMillis();
invocation.getMethod().invoke(targetObject, invocation.getArguments());
LOGGER.info("{}({}) {} method execute {}dms.", targetObject.getClass().getName(),
beanName, invocation.getMethod().getName(),
(System.currentTimeMillis() - startTime));
} catch (Throwable e) {
throw new RuntimeException(e);
} finally {
AsyncInitializeBeanMethodInvoker.this.asyncMethodFinish();
}
}
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation of AsyncBeanInitRunnable is robust. However, consider enhancing error logging by including more context about the failure.

- throw new RuntimeException(e);
+ throw new RuntimeException("Error executing async initialization for method: " + invocation.getMethod().getName() + " in bean: " + beanName, e);

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change
private class AsyncBeanInitRunnable implements Runnable {
private final MethodInvocation invocation;
public AsyncBeanInitRunnable(MethodInvocation invocation) {
this.invocation = invocation;
}
@Override
public void run() {
try {
long startTime = System.currentTimeMillis();
invocation.getMethod().invoke(targetObject, invocation.getArguments());
LOGGER.info("{}({}) {} method execute {}dms.", targetObject.getClass().getName(),
beanName, invocation.getMethod().getName(),
(System.currentTimeMillis() - startTime));
} catch (Throwable e) {
throw new RuntimeException(e);
} finally {
AsyncInitializeBeanMethodInvoker.this.asyncMethodFinish();
}
}
}
private class AsyncBeanInitRunnable implements Runnable {
private final MethodInvocation invocation;
public AsyncBeanInitRunnable(MethodInvocation invocation) {
this.invocation = invocation;
}
@Override
public void run() {
try {
long startTime = System.currentTimeMillis();
invocation.getMethod().invoke(targetObject, invocation.getArguments());
LOGGER.info("{}({}) {} method execute {}dms.", targetObject.getClass().getName(),
beanName, invocation.getMethod().getName(),
(System.currentTimeMillis() - startTime));
} catch (Throwable e) {
throw new RuntimeException("Error executing async initialization for method: " + invocation.getMethod().getName() + " in bean: " + beanName, e);
} finally {
AsyncInitializeBeanMethodInvoker.this.asyncMethodFinish();
}
}
}

asyncMethodFinish();
}
});
asyncInitMethodManager.submitTask(new AsyncBeanInitRunnable(invocation));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tip

Codebase Verification

Ensure proper handling of exceptions in the asynchronous task submission.

The search results indicate that there are various instances of exception handling across the codebase, but none specifically around the submitTask method in the AsyncInitializeBeanMethodInvoker class. This suggests that exceptions during task submission might not be handled properly in this specific context.

  • File: sofa-boot-project/sofa-boot-core/runtime-sofa-boot/src/main/java/com/alipay/sofa/runtime/async/AsyncInitializeBeanMethodInvoker.java
  • Line: 78

Please review and ensure that exceptions during the asynchronous task submission are properly handled to avoid potential runtime issues.

Analysis chain

Ensure proper handling of exceptions in the asynchronous task submission.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that exceptions during task submission are handled properly.
# Test: Search for exception handling patterns around task submissions.
rg --type java 'submit.*catch' --context 5

Length of output: 44



Script:

#!/bin/bash
# Description: Verify that exceptions during task submission are handled properly in the AsyncInitializeBeanMethodInvoker class and related classes.
# Test: Search for exception handling patterns in the AsyncInitializeBeanMethodInvoker class and related classes.
rg --type java 'catch' --context 5

Length of output: 261503

Comment on lines +269 to +308
private class AsyncSpringContextRunnable implements Runnable {
private final DeploymentDescriptor deployment;
private final CountDownLatch latch;
private final List<Future<?>> futures;

public AsyncSpringContextRunnable(DeploymentDescriptor deployment, CountDownLatch latch,
List<Future<?>> futures) {
this.deployment = deployment;
this.latch = latch;
this.futures = futures;
}

@Override
public void run() {
String oldName = Thread.currentThread().getName();
try {
Thread.currentThread().setName("sofa-module-refresh-" + deployment.getModuleName());
if (deployment.isSpringPowered() && !application.getFailed().contains(deployment)) {
SpringContextInstallStage.this.refreshAndCollectCost(deployment);
}
DependencyTree.Entry<String, DeploymentDescriptor> entry = application
.getDeployRegistry().getEntry(deployment.getModuleName());
if (entry != null && entry.getDependsOnMe() != null) {
for (DependencyTree.Entry<String, DeploymentDescriptor> child : entry
.getDependsOnMe()) {
child.getDependencies().remove(entry);
if (child.getDependencies().size() == 0) {
SpringContextInstallStage.this.refreshRecursively(child.get(), latch,
futures);
}
}
}
} catch (Throwable t) {
LOGGER.error(ErrorCode.convert("01-11002", deployment.getName()), t);
throw new RuntimeException(ErrorCode.convert("01-11002", deployment.getName()), t);
} finally {
latch.countDown();
Thread.currentThread().setName(oldName);
}
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The AsyncSpringContextRunnable class is well-implemented. Consider adding error handling within the run method to manage exceptions more gracefully.

- throw new RuntimeException(ErrorCode.convert("01-11002", deployment.getName()), t);
+ LOGGER.error("Error during the refresh of ApplicationContext for module: " + deployment.getName(), t);
+ throw new DeploymentException("Failed to refresh ApplicationContext for module: " + deployment.getName(), t);

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change
private class AsyncSpringContextRunnable implements Runnable {
private final DeploymentDescriptor deployment;
private final CountDownLatch latch;
private final List<Future<?>> futures;
public AsyncSpringContextRunnable(DeploymentDescriptor deployment, CountDownLatch latch,
List<Future<?>> futures) {
this.deployment = deployment;
this.latch = latch;
this.futures = futures;
}
@Override
public void run() {
String oldName = Thread.currentThread().getName();
try {
Thread.currentThread().setName("sofa-module-refresh-" + deployment.getModuleName());
if (deployment.isSpringPowered() && !application.getFailed().contains(deployment)) {
SpringContextInstallStage.this.refreshAndCollectCost(deployment);
}
DependencyTree.Entry<String, DeploymentDescriptor> entry = application
.getDeployRegistry().getEntry(deployment.getModuleName());
if (entry != null && entry.getDependsOnMe() != null) {
for (DependencyTree.Entry<String, DeploymentDescriptor> child : entry
.getDependsOnMe()) {
child.getDependencies().remove(entry);
if (child.getDependencies().size() == 0) {
SpringContextInstallStage.this.refreshRecursively(child.get(), latch,
futures);
}
}
}
} catch (Throwable t) {
LOGGER.error(ErrorCode.convert("01-11002", deployment.getName()), t);
throw new RuntimeException(ErrorCode.convert("01-11002", deployment.getName()), t);
} finally {
latch.countDown();
Thread.currentThread().setName(oldName);
}
}
@Override
public void run() {
String oldName = Thread.currentThread().getName();
try {
Thread.currentThread().setName("sofa-module-refresh-" + deployment.getModuleName());
if (deployment.isSpringPowered() && !application.getFailed().contains(deployment)) {
SpringContextInstallStage.this.refreshAndCollectCost(deployment);
}
DependencyTree.Entry<String, DeploymentDescriptor> entry = application
.getDeployRegistry().getEntry(deployment.getModuleName());
if (entry != null && entry.getDependsOnMe() != null) {
for (DependencyTree.Entry<String, DeploymentDescriptor> child : entry
.getDependsOnMe()) {
child.getDependencies().remove(entry);
if (child.getDependencies().size() == 0) {
SpringContextInstallStage.this.refreshRecursively(child.get(), latch,
futures);
}
}
}
} catch (Throwable t) {
LOGGER.error(ErrorCode.convert("01-11002", deployment.getName()), t);
LOGGER.error("Error during the refresh of ApplicationContext for module: " + deployment.getName(), t);
throw new DeploymentException("Failed to refresh ApplicationContext for module: " + deployment.getName(), t);
} finally {
latch.countDown();
Thread.currentThread().setName(oldName);
}
}

Comment on lines +171 to +172
healthIndicators.forEach((key, value) -> healthCheckExecutor.execute(
new AsyncHealthIndicatorRunnable(key, value, healthMap, parallelResult, countDownLatch)));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation of parallel health checks using AsyncHealthIndicatorRunnable is effective. Ensure that the timeout handling is robust and consider logging more details about the timeout event.

- healthMap.put("parallelCheck", new Health.Builder().withDetail("timeout", getParallelCheckTimeout()).status(Status.UNKNOWN).build());
+ logger.warn("Parallel health check timed out after {}ms.", getParallelCheckTimeout());
+ healthMap.put("parallelCheck", new Health.Builder().withDetail("timeout", getParallelCheckTimeout()).status(Status.UNKNOWN).build());

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change
healthIndicators.forEach((key, value) -> healthCheckExecutor.execute(
new AsyncHealthIndicatorRunnable(key, value, healthMap, parallelResult, countDownLatch)));
healthIndicators.forEach((key, value) -> healthCheckExecutor.execute(
new AsyncHealthIndicatorRunnable(key, value, healthMap, parallelResult, countDownLatch)));
logger.warn("Parallel health check timed out after {}ms.", getParallelCheckTimeout());
healthMap.put("parallelCheck", new Health.Builder().withDetail("timeout", getParallelCheckTimeout()).status(Status.UNKNOWN).build());

Comment on lines +115 to +116
readinessHealthCheckers.forEach((String key, HealthChecker value) -> healthCheckExecutor.execute(
new AsyncHealthCheckRunnable(key, value, healthMap, parallelResult, countDownLatch)));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation of parallel health checks using AsyncHealthCheckRunnable is effective. Ensure that the timeout handling is robust and consider logging more details about the timeout event.

- healthMap.put("parallelCheck", new Health.Builder().withDetail("timeout", getParallelCheckTimeout()).status(Status.UNKNOWN).build());
+ logger.warn("Parallel health check timed out after {}ms.", getParallelCheckTimeout());
+ healthMap.put("parallelCheck", new Health.Builder().withDetail("timeout", getParallelCheckTimeout()).status(Status.UNKNOWN).build());

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change
readinessHealthCheckers.forEach((String key, HealthChecker value) -> healthCheckExecutor.execute(
new AsyncHealthCheckRunnable(key, value, healthMap, parallelResult, countDownLatch)));
readinessHealthCheckers.forEach((String key, HealthChecker value) -> healthCheckExecutor.execute(
new AsyncHealthCheckRunnable(key, value, healthMap, parallelResult, countDownLatch)));
logger.warn("Parallel health check timed out after {}ms.", getParallelCheckTimeout());
healthMap.put("parallelCheck", new Health.Builder().withDetail("timeout", getParallelCheckTimeout()).status(Status.UNKNOWN).build());

Copy link

codecov bot commented May 27, 2024

Codecov Report

Attention: Patch coverage is 77.89474% with 21 lines in your changes are missing coverage. Please review.

Project coverage is 83.18%. Comparing base (c743030) to head (083cd71).

Files Patch % Lines
...a/boot/actuator/health/HealthCheckerProcessor.java 81.81% 6 Missing ⚠️
...ofa/boot/isle/stage/SpringContextInstallStage.java 76.00% 3 Missing and 3 partials ⚠️
...boot/actuator/health/HealthIndicatorProcessor.java 77.27% 5 Missing ⚠️
...untime/async/AsyncInitializeBeanMethodInvoker.java 73.33% 4 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff            @@
##             master    #1327   +/-   ##
=========================================
  Coverage     83.17%   83.18%           
+ Complexity     2958     2949    -9     
=========================================
  Files           337      337           
  Lines          9707     9739   +32     
  Branches       1172     1174    +2     
=========================================
+ Hits           8074     8101   +27     
- Misses         1120     1125    +5     
  Partials        513      513           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@crazysaltfish crazysaltfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@HzjNeverStop HzjNeverStop merged commit 88347b5 into sofastack:master May 28, 2024
6 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants