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

feat: add Health Proto and Update gRPC/HTTP Health Registration #1632

Merged
merged 2 commits into from
Sep 26, 2024

Conversation

ucatbas
Copy link
Contributor

@ucatbas ucatbas commented Sep 25, 2024

This PR introduces several updates related to the health check. Specifically, it adds a new health.proto, and updates the registration of both gRPC and HTTP health checks. The API documentation has also been revised to reflect these changes.

Changes:

  • Introduced a new health.proto file to define HealthCheckRequest and HealthCheckResponse messages, along with the Health service, in alignment with gRPC health check standards.

  • Modified the gRPC service registration to integrate the health checking functionality. Now, the health service is correctly registered, allowing clients to use both Check and Watch methods for monitoring service health.

Summary by CodeRabbit

  • New Features

    • Introduced a new health check service with a Check method and a Watch method for continuous health status updates.
    • Added a new query parameter service to the health check endpoint.
    • Defined a new enumeration ServingStatus for clearer service health representation.
  • Bug Fixes

    • Renamed HealthResponse to HealthCheckResponse for consistency in the API documentation.
  • Chores

    • Streamlined health check service registration process, reducing redundancy in the code.

Copy link

coderabbitai bot commented Sep 25, 2024

Walkthrough

The pull request introduces significant changes to the API documentation and health check functionality. Key modifications include renaming the HealthResponse to HealthCheckResponse, adding a new optional query parameter service, and updating request body references. The health check server now utilizes a new package for health checks, simplifying service registration. Additionally, validation logic for health-related protocol buffer messages has been introduced, while previous validation methods for HealthRequest and HealthResponse have been removed.

Changes

Files Change Summary
docs/api-reference/apidocs.swagger.json Renamed HealthResponse to HealthCheckResponse, added service query parameter, updated WatchBody reference, and added ServingStatus definition.
docs/api-reference/openapiv2/apidocs.swagger.json Similar changes as above, with updates to response schema and property types.
internal/servers/healthServer.go Transitioned to new health check package, updated method signatures to use new types, and modified response handling.
internal/servers/server.go Simplified health server registration process, removed redundant client instantiation, and updated endpoint registration.
pkg/pb/base/v1/health.pb.validate.go Introduced validation methods for health check messages, including multi-error types for validation failures.
pkg/pb/base/v1/service.pb.validate.go Removed validation methods and error types for HealthRequest and HealthResponse, simplifying the code.
proto/base/v1/health.proto Defined new gRPC service for health checks with HealthCheckRequest and HealthCheckResponse, including ServingStatus enum.
proto/base/v1/service.proto Removed HealthRequest and HealthResponse definitions, along with the Health service.

Possibly related PRs

Poem

🐰 In the meadow where changes bloom,
Health checks thrive, dispelling gloom.
With service added, responses clear,
The rabbit hops, spreading cheer!
New paths to health, we now can trace,
A joyful leap in our code's embrace! 🌼


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>, please review it.
    • 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 gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @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.
    • @coderabbitai help me debug CodeRabbit configuration file.

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 using 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 do a full 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 configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration 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: 4

🧹 Outside diff range and nitpick comments (5)
internal/servers/healthServer.go (1)

27-27: LGTM: Watch method signature updated correctly. Consider addressing the TODO comment.

The Watch method signature has been successfully updated to use the new v1 types, which is consistent with the changes in the rest of the file.

There's a TODO comment above this method. Would you like assistance in implementing the Watch method or creating a GitHub issue to track this task?

internal/servers/server.go (1)

305-307: LGTM: Health handler registration added for HTTP server

The health handler is now properly registered for the HTTP server using grpcV1.RegisterHealthHandler. This change aligns with the PR objectives of updating the HTTP health registration.

For consistency with other handler registrations, consider refactoring the error handling to a single line:

-		if err = grpcV1.RegisterHealthHandler(ctx, mux, conn); err != nil {
-			return err
-		}
+		if err = grpcV1.RegisterHealthHandler(ctx, mux, conn); err != nil { return err }

This change would make the health handler registration consistent with the style used for other handlers in this file.

docs/api-reference/openapiv2/apidocs.swagger.json (1)

3079-3087: Well-defined ServingStatus enum added

The addition of the ServingStatus enum is a welcome improvement, providing a clear and standardized set of possible values for the health check status. This enhances the API's clarity and usability.

However, to improve the documentation:

Consider adding descriptions for the "SERVING" and "NOT_SERVING" values as well, to provide a complete understanding of when each status is used. For example:

 "ServingStatus": {
   "type": "string",
   "enum": [
     "SERVING",
     "NOT_SERVING",
     "SERVICE_UNKNOWN"
   ],
-  "description": " - SERVICE_UNKNOWN: Used only by the Watch method."
+  "description": " - SERVING: The service is operational and ready to handle requests.\n - NOT_SERVING: The service is not operational and cannot handle requests.\n - SERVICE_UNKNOWN: Used only by the Watch method when the service status cannot be determined."
 }
docs/api-reference/apidocs.swagger.json (2)

68-75: LGTM: Added optional 'service' parameter to health check endpoint

The addition of the optional service query parameter to the /healthz endpoint is a valuable enhancement. It allows for more granular health checks by enabling the specification of a particular service. This change is in line with the PR objectives of updating the gRPC/HTTP health registration.

Consider updating the API documentation to include information about this new parameter, explaining its purpose and usage.


3099-3109: LGTM: Added ServingStatus definition

The addition of the ServingStatus definition as a string enum with clear status options (UNKNOWN, SERVING, NOT_SERVING, SERVICE_UNKNOWN) is a valuable enhancement. This provides a standardized set of statuses for health check responses, improving the API's consistency and usability.

Consider adding descriptions for the other status values (UNKNOWN, SERVING, NOT_SERVING) to provide complete documentation for API users. For example:

 "ServingStatus": {
   "type": "string",
   "enum": [
     "UNKNOWN",
     "SERVING",
     "NOT_SERVING",
     "SERVICE_UNKNOWN"
   ],
   "default": "UNKNOWN",
   "description": "Enum representing the serving status of the service.",
+  "enumDescriptions": [
+    "The serving status is unknown.",
+    "The service is serving.",
+    "The service is not serving.",
+    "Used only by the Watch method."
+  ]
 }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 1f1063c and 55ce8c5.

🔇 Files ignored due to path filters (6)
  • pkg/pb/base/v1/health.pb.go is excluded by !**/*.pb.go
  • pkg/pb/base/v1/health.pb.gw.go is excluded by !**/*.pb.gw.go
  • pkg/pb/base/v1/health_grpc.pb.go is excluded by !**/*.pb.go
  • pkg/pb/base/v1/service.pb.go is excluded by !**/*.pb.go
  • pkg/pb/base/v1/service.pb.gw.go is excluded by !**/*.pb.gw.go
  • pkg/pb/base/v1/service_grpc.pb.go is excluded by !**/*.pb.go
📒 Files selected for processing (8)
  • docs/api-reference/apidocs.swagger.json (6 hunks)
  • docs/api-reference/openapiv2/apidocs.swagger.json (6 hunks)
  • internal/servers/healthServer.go (2 hunks)
  • internal/servers/server.go (2 hunks)
  • pkg/pb/base/v1/health.pb.validate.go (1 hunks)
  • pkg/pb/base/v1/service.pb.validate.go (0 hunks)
  • proto/base/v1/health.proto (1 hunks)
  • proto/base/v1/service.proto (0 hunks)
💤 Files not reviewed due to no reviewable changes (2)
  • pkg/pb/base/v1/service.pb.validate.go
  • proto/base/v1/service.proto
✅ Files skipped from review due to trivial changes (1)
  • pkg/pb/base/v1/health.pb.validate.go
🧰 Additional context used
buf
proto/base/v1/health.proto

4-4: import "google/api/annotations.proto": file does not exist

(COMPILE)

🔇 Additional comments not posted (13)
internal/servers/healthServer.go (4)

6-6: LGTM: Import statement updated correctly.

The new import statement for the v1 package is consistent with the transition from grpc_health_v1 to the new package as mentioned in the PR summary.


13-13: LGTM: HealthServer struct updated correctly.

The HealthServer struct now correctly embeds v1.UnimplementedHealthServer, which is in line with the transition to the new v1 package and follows gRPC best practices for forward compatibility.


22-23: LGTM: Check method updated correctly with improved implementation.

The Check method has been successfully updated to use the new v1 types. The implementation now returns a concrete v1.HealthCheckResponse with a SERVING status, which is an improvement over the previous implementation.


Line range hint 1-37: Summary: Health server implementation successfully updated to use new v1 package.

The changes in this file successfully transition the health server implementation from using grpc_health_v1 to the new v1 package from github.com/Permify/permify/pkg/pb/base/v1. This update includes:

  1. Updated import statements
  2. Modified HealthServer struct to embed the new UnimplementedHealthServer
  3. Updated Check and Watch method signatures
  4. Improved Check method implementation to return a concrete response

These changes align well with the PR objectives and improve the overall health check functionality. The only remaining item is the unimplemented Watch method, which has been noted.

proto/base/v1/health.proto (2)

15-23: LGTM: HealthCheckResponse and ServingStatus are well-defined

The HealthCheckResponse message and ServingStatus enum are well-structured and cover all necessary states for a health check response. The use of an enum for the status ensures type safety and clear semantics.


25-94: LGTM: Health service is well-structured

The Health service definition follows gRPC best practices. The inclusion of both Check and Watch methods provides flexibility for different health monitoring scenarios. The HTTP and OpenAPI annotations for the Check method facilitate easy integration with RESTful APIs and API documentation tools.

internal/servers/server.go (3)

184-184: LGTM: Health server registration added

The health server is now properly registered for the main gRPC server using grpcV1.RegisterHealthServer. This change aligns with the PR objectives of updating the gRPC health registration.


191-191: LGTM: Health server registration added for invoke server

The health server is now properly registered for the invoke server, maintaining consistency with the main gRPC server. This ensures that health check functionality is available for both servers.


Line range hint 184-307: Summary: Health check implementation successfully updated

The changes in this file successfully implement the health check functionality across all server types (gRPC, invoke, and HTTP). The implementation is consistent and aligns with the PR objectives. These updates will improve the robustness and reliability of health monitoring within the application.

Key improvements:

  1. Health server registration for the main gRPC server
  2. Health server registration for the invoke server
  3. Health handler registration for the HTTP server

These changes ensure that clients can utilize both the Check and Watch methods for monitoring the health of the service, as mentioned in the PR objectives.

docs/api-reference/openapiv2/apidocs.swagger.json (2)

2198-2204: Improved type safety for HealthCheckResponse status

The modification of the status property in the HealthCheckResponse definition to reference #/definitions/ServingStatus instead of a simple string type is a positive change. This update likely provides better type safety and potentially more detailed status information, improving the API's robustness and clarity.


1382-1382: Updated reference to Watch.WatchBody

The change in reference from #/definitions/WatchBody to #/definitions/Watch.WatchBody is likely part of a reorganization of the API definitions. This change can improve clarity by grouping related definitions.

To ensure this change doesn't introduce any issues, please run the following verification:

✅ Verification successful

Watch.WatchBody Reference Updated Successfully

The reference to #/definitions/Watch.WatchBody has been verified in all instances of apidocs.swagger.json. The Watch.WatchBody definition exists, and there are no remaining references to the old WatchBody definition.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify that the Watch.WatchBody definition exists and is correctly referenced

# Check if the Watch.WatchBody definition exists
if jq -e '.definitions["Watch.WatchBody"]' apidocs.swagger.json > /dev/null; then
    echo "Watch.WatchBody definition exists."
else
    echo "Error: Watch.WatchBody definition not found."
    exit 1
fi

# Check if there are any remaining references to the old WatchBody definition
if jq -e '.. | objects | select(has("$ref")) | select(.["$ref"] == "#/definitions/WatchBody")' apidocs.swagger.json > /dev/null; then
    echo "Warning: Found references to old WatchBody definition. These should be updated."
else
    echo "No references to old WatchBody definition found."
fi

Length of output: 249


Script:

#!/bin/bash
# Locate apidocs.swagger.json in the repository
FILE_PATH=$(fd --search-path . --type f --name "apidocs.swagger.json")

if [ -z "$FILE_PATH" ]; then
    echo "Error: apidocs.swagger.json not found in the repository."
    exit 1
else
    echo "Found apidocs.swagger.json at: $FILE_PATH"
fi

# Verify that the Watch.WatchBody definition exists and is correctly referenced
if jq -e '.definitions["Watch.WatchBody"]' "$FILE_PATH" > /dev/null; then
    echo "Watch.WatchBody definition exists."
else
    echo "Error: Watch.WatchBody definition not found."
    exit 1
fi

# Check if there are any remaining references to the old WatchBody definition
if jq -e '.. | objects | select(has("$ref")) | select(.["$ref"] == "#/definitions/WatchBody")' "$FILE_PATH" > /dev/null; then
    echo "Warning: Found references to old WatchBody definition. These should be updated."
else
    echo "No references to old WatchBody definition found."
fi

Length of output: 498


Script:

#!/bin/bash
# Locate apidocs.swagger.json in the repository using correct fd syntax
FILE_PATH=$(fd "apidocs.swagger.json" --type f)

if [ -z "$FILE_PATH" ]; then
    echo "Error: apidocs.swagger.json not found in the repository."
    exit 1
else
    echo "Found apidocs.swagger.json at: $FILE_PATH"
fi

# Verify that the Watch.WatchBody definition exists and is correctly referenced
if jq -e '.definitions["Watch.WatchBody"]' "$FILE_PATH" > /dev/null; then
    echo "Watch.WatchBody definition exists."
else
    echo "Error: Watch.WatchBody definition not found."
    exit 1
fi

# Check if there are any remaining references to the old WatchBody definition
if jq -e '.. | objects | select(has("$ref")) | select(.["$ref"] == "#/definitions/WatchBody")' "$FILE_PATH" > /dev/null; then
    echo "Warning: Found references to old WatchBody definition. These should be updated."
else
    echo "No references to old WatchBody definition found."
fi

Length of output: 885


Script:

#!/bin/bash
# Locate all instances of apidocs.swagger.json in the repository using correct fd syntax
FILE_PATHS=$(fd "apidocs.swagger.json" --type f)

if [ -z "$FILE_PATHS" ]; then
    echo "Error: apidocs.swagger.json not found in the repository."
    exit 1
else
    echo "Found apidocs.swagger.json at:"
    echo "$FILE_PATHS"
fi

# Iterate over each found file path
while IFS= read -r FILE_PATH; do
    echo "Processing $FILE_PATH..."
    
    # Verify that the Watch.WatchBody definition exists and is correctly referenced
    if jq -e '.definitions["Watch.WatchBody"]' "$FILE_PATH" > /dev/null; then
        echo "  - Watch.WatchBody definition exists."
    else
        echo "  - Error: Watch.WatchBody definition not found in $FILE_PATH."
        exit 1
    fi
    
    # Check if there are any remaining references to the old WatchBody definition
    if jq -e '.. | objects | select(has("$ref")) | select(.["$ref"] == "#/definitions/WatchBody")' "$FILE_PATH" > /dev/null; then
        echo "  - Warning: Found references to old WatchBody definition in $FILE_PATH. These should be updated."
    else
        echo "  - No references to old WatchBody definition found in $FILE_PATH."
    fi
done <<< "$FILE_PATHS"

Length of output: 1888

docs/api-reference/apidocs.swagger.json (2)

58-58: LGTM: Updated health check response schema

The change from HealthResponse to HealthCheckResponse in the /healthz endpoint's response schema aligns well with the PR objectives. This update ensures consistency in naming conventions across the API and reflects the enhanced health check functionality.


2208-2214: LGTM: Added HealthCheckResponse definition

The addition of the HealthCheckResponse definition with a status field referencing ServingStatus is a positive enhancement. This change supports the PR objectives of updating the health check functionality and allows for more detailed health status reporting.

Please ensure that the #/definitions/ServingStatus definition exists and is correctly defined in the schema. Run the following command to verify:

#!/bin/bash
# Verify the existence and content of the ServingStatus definition
jq '.definitions.ServingStatus' docs/api-reference/apidocs.swagger.json

Comment on lines +1 to +9
syntax = "proto3";
package base.v1;

import "google/api/annotations.proto";
import "protoc-gen-openapiv2/options/annotations.proto";
import "validate/validate.proto";

option go_package = "github.com/Permify/permify/pkg/pb/base/v1";

Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue

Verify the import for "google/api/annotations.proto"

The file structure and package naming follow best practices. However, there's an issue with one of the imports.

The static analysis tool indicates that the file "google/api/annotations.proto" does not exist. This could lead to compilation errors. Please ensure that this dependency is correctly installed and the import path is accurate.

To resolve this:

  1. Check if the google/api package is installed in your project.
  2. If it's not installed, you may need to add it to your project dependencies.
  3. If it is installed, verify the import path is correct.

If you need assistance with installing or configuring the dependency, please let me know.

🧰 Tools
buf

4-4: import "google/api/annotations.proto": file does not exist

(COMPILE)

Comment on lines +11 to +13
message HealthCheckRequest {
string service = 1;
}
Copy link

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Consider adding validation to the service field

The HealthCheckRequest message structure is simple and appropriate. However, to improve robustness, consider adding validation to the service field.

You could use the validate.rules option to ensure the service field is not empty when provided. Here's an example of how you could modify the message:

 message HealthCheckRequest {
-  string service = 1;
+  string service = 1 [(validate.rules).string = {min_len: 1}];
 }

This change would ensure that if a service name is provided, it's not an empty string.

Committable suggestion was skipped due to low confidence.

Comment on lines +30 to +90
option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_operation) = {
summary: "health api"
tags: ["Health"]
operation_id: "health.check"
description: ""
extensions: {
key: "x-codeSamples"
value: {
list_value: {
values: {
struct_value: {
fields: {
key: "lang"
value: {string_value: ""}
}
fields: {
key: "label"
value: {string_value: ""}
}
fields: {
key: "source"
value: {string_value: ""}
}
}
}
values: {
struct_value: {
fields: {
key: "lang"
value: {string_value: ""}
}
fields: {
key: "label"
value: {string_value: ""}
}
fields: {
key: "source"
value: {string_value: ""}
}
}
}
values: {
struct_value: {
fields: {
key: "lang"
value: {string_value: ""}
}
fields: {
key: "label"
value: {string_value: ""}
}
fields: {
key: "source"
value: {string_value: ""}
}
}
}
}
}
}
};
Copy link

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Enhance OpenAPI annotations for better documentation

While the OpenAPI annotations are present, some fields are left empty. Improving these annotations would enhance the API documentation.

Consider updating the following fields in the OpenAPI annotations:

  1. Add a more detailed description for the operation.
  2. Provide example requests and responses.
  3. Include information about possible error responses.

Here's an example of how you could improve the annotations:

 option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_operation) = {
   summary: "health api"
   tags: ["Health"]
   operation_id: "health.check"
-  description: ""
+  description: "Checks the health status of the requested service"
   extensions: {
     key: "x-codeSamples"
     value: {
       list_value: {
         values: {
           struct_value: {
             fields: {
               key: "lang"
-              value: {string_value: ""}
+              value: {string_value: "curl"}
             }
             fields: {
               key: "label"
-              value: {string_value: ""}
+              value: {string_value: "cURL"}
             }
             fields: {
               key: "source"
-              value: {string_value: ""}
+              value: {string_value: "curl -X GET \"https://api.example.com/healthz?service=myservice\""}
             }
           }
         }
       }
     }
   }
+  responses: {
+    key: "200"
+    value: {
+      description: "Successful health check response"
+      schema: {
+        json_schema: {
+          ref: "#/definitions/base.v1.HealthCheckResponse"
+        }
+      }
+    }
+  }
+  responses: {
+    key: "404"
+    value: {
+      description: "Service not found"
+    }
+  }
 };

These improvements will make the API documentation more informative and user-friendly.

Committable suggestion was skipped due to low confidence.

@@ -1371,7 +1379,7 @@
"in": "body",
"required": true,
"schema": {
"$ref": "#/definitions/WatchBody"
"$ref": "#/definitions/Watch.WatchBody"
Copy link

Choose a reason for hiding this comment

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

💡 Codebase verification

Issue: Watch.WatchBody definition not found

The referenced definition #/definitions/Watch.WatchBody does not exist in apidocs.swagger.json. Please verify the definition name or update the reference accordingly.

🔗 Analysis chain

LGTM: Updated Watch method request body reference

The change in the request body reference for the Watch method from WatchBody to Watch.WatchBody appears to be part of a definition restructuring. This update is in line with the PR objectives of improving the API documentation.

Please ensure that the #/definitions/Watch.WatchBody definition exists and is correctly defined in the schema. Run the following command to verify:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify the existence of the Watch.WatchBody definition
jq '.definitions["Watch.WatchBody"]' docs/api-reference/apidocs.swagger.json

Length of output: 277

@tolgaOzen tolgaOzen changed the title Add Health Proto and Update gRPC/HTTP Health Registration feat: add Health Proto and Update gRPC/HTTP Health Registration Sep 26, 2024
@ucatbas ucatbas merged commit 9d95d27 into master Sep 26, 2024
11 of 13 checks passed
@ucatbas ucatbas deleted the ufuk/healthproto branch September 26, 2024 15:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant