feat: update quickstart with docker checks and grpc web ui#356
feat: update quickstart with docker checks and grpc web ui#356
Conversation
PR Validation FailedPR description validation failed Issues found:
Please fill out the form to fix this: Open Form |
WalkthroughAdds a colocated gRPC UI stack (nginx gRPC proxy + grpcui), many gRPC sample payloads, a static gRPC UI helper page, and startup script changes to install, configure and optionally enable the gRPC UI in the quick-start environment. Changes
Sequence Diagram(s)mermaid (Note: grpcui mounts local proto dirs and targets grpc-proxy:9000; nginx config routes to backend services.) 🚥 Pre-merge checks | ✅ 1✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
quick-start/grpc-samples/predator/ServerMetadata.json (1)
1-1: Consider adding example metadata fields if this should demonstrate structure.Most sample JSON files in the grpc-samples directory contain example data and fields. However,
ServerLive.json(also in the predator directory) is similarly empty, suggesting empty metadata may be intentional for this service. IfServerMetadata.jsonis meant as a reference for structure, consider populating it with example fields. Otherwise, the empty object is valid as-is.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@quick-start/grpc-samples/predator/ServerMetadata.json` at line 1, ServerMetadata.json is currently an empty object but should either demonstrate expected metadata structure or remain intentionally empty; decide and act accordingly: if it’s meant as a schema/example, populate ServerMetadata.json with representative fields (e.g., serverName, version, host, port, maxPlayers, region, maintenanceWindow, tags, createdAt) so consumers see the expected shape, and mirror similar example entries into ServerLive.json if both are intended as samples; otherwise, add a short comment in the file or repository README indicating the empty object is intentional to avoid confusion.quick-start/docker-compose.yml (1)
958-976: Consider pinning image versions for reproducibility.Using
nginx:latestandfullstorydev/grpcui:latestcan lead to inconsistent behavior across environments if the upstream images change. For a quickstart environment, this may be acceptable, but pinning versions improves reproducibility.Example with pinned versions
grpc-proxy: - image: nginx:latest + image: nginx:1.25 container_name: grpc-proxygrpcui: - image: fullstorydev/grpcui:latest + image: fullstorydev/grpcui:v1.4.1 container_name: grpcui🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@quick-start/docker-compose.yml` around lines 958 - 976, Replace the floating "latest" tags to ensure reproducible builds: in the docker-compose.yml entries for the grpc-proxy service (image: nginx:latest) and the grpcui service (image: fullstorydev/grpcui:latest) set fixed image tags or digests (e.g., nginx:1.25.2 or nginx@sha256:..., and fullstorydev/grpcui:v0.x.y or fullstorydev/grpcui@sha256:...) so the grpc-proxy and grpcui services always pull the known versions; update the image fields for the grpc-proxy and grpcui services accordingly and commit the pinned tags or digests.quick-start/grpc-samples/inferflow/InferPointWise.json (1)
12-25: Schema mismatch between JSON file and HTML helper page.The
targetInputSchemahere has 3 fields (price,rating,category), but the corresponding sample in the HTML helper page (lines 234-237) only shows 2 fields (price,rating). Consider aligning them for consistency, or ensure both variants are documented.Also, the empty string
""for thecategoryfield infeatureValuesmay cause issues if the service expects base64-encoded bytes for all values.Option: Remove category to match HTML sample
"targetInputSchema": [ { "name": "price", "dataType": "DataTypeFP32", "vectorDim": 0 }, - { "name": "rating", "dataType": "DataTypeFP32", "vectorDim": 0 }, - { "name": "category", "dataType": "DataTypeString", "vectorDim": 0 } + { "name": "rating", "dataType": "DataTypeFP32", "vectorDim": 0 } ], "targets": [ { "id": "product_101", - "featureValues": ["AAAAAA==", "AAAAAA==", ""] + "featureValues": ["AAAAAA==", "AAAAAA=="] }, { "id": "product_202", - "featureValues": ["AAAAAA==", "AAAAAA==", ""] + "featureValues": ["AAAAAA==", "AAAAAA=="] } ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@quick-start/grpc-samples/inferflow/InferPointWise.json` around lines 12 - 25, The targetInputSchema in InferPointWise.json defines three fields (price, rating, category) but the HTML helper sample only shows two; update them to match: either remove the "category" entry from targetInputSchema and drop the third element from each targets[].featureValues (for product_101 and product_202), or update the HTML helper sample to include the "category" field so both docs match. Also ensure each featureValues entry is valid for the declared dataType (if category expects base64-encoded bytes, replace the empty string "" with a proper base64 value or remove the field if omitted).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@quick-start/docker-compose.yml`:
- Around line 964-966: The grpc-proxy service is mapping host port 8095 (ports:
"8095:80") which conflicts with skye-trigger's host mapping ("8095:8080");
change grpc-proxy's host port to an unused port (e.g., "8096:80" or another free
port) in the docker-compose.yml service stanza for grpc-proxy to avoid the
collision, then update the corresponding helper page URL reference in start.sh
that points to the grpc-proxy HTTP host:port so it uses the new host port
(ensure any docker-compose service references or environment variables that
assume 8095 are updated to the new port).
In `@quick-start/start.sh`:
- Around line 1125-1127: Update the hardcoded helper page URL in start.sh so it
matches the docker-compose port change: replace the "http://localhost:8095"
reference in the echo that prints the helper page URL to use the new grpc-proxy
HTTP port (e.g., "http://localhost:8097"); ensure the adjacent echo that
mentions sample JSON files remains unchanged and test startup output to confirm
the new port is displayed.
---
Nitpick comments:
In `@quick-start/docker-compose.yml`:
- Around line 958-976: Replace the floating "latest" tags to ensure reproducible
builds: in the docker-compose.yml entries for the grpc-proxy service (image:
nginx:latest) and the grpcui service (image: fullstorydev/grpcui:latest) set
fixed image tags or digests (e.g., nginx:1.25.2 or nginx@sha256:..., and
fullstorydev/grpcui:v0.x.y or fullstorydev/grpcui@sha256:...) so the grpc-proxy
and grpcui services always pull the known versions; update the image fields for
the grpc-proxy and grpcui services accordingly and commit the pinned tags or
digests.
In `@quick-start/grpc-samples/inferflow/InferPointWise.json`:
- Around line 12-25: The targetInputSchema in InferPointWise.json defines three
fields (price, rating, category) but the HTML helper sample only shows two;
update them to match: either remove the "category" entry from targetInputSchema
and drop the third element from each targets[].featureValues (for product_101
and product_202), or update the HTML helper sample to include the "category"
field so both docs match. Also ensure each featureValues entry is valid for the
declared dataType (if category expects base64-encoded bytes, replace the empty
string "" with a proper base64 value or remove the field if omitted).
In `@quick-start/grpc-samples/predator/ServerMetadata.json`:
- Line 1: ServerMetadata.json is currently an empty object but should either
demonstrate expected metadata structure or remain intentionally empty; decide
and act accordingly: if it’s meant as a schema/example, populate
ServerMetadata.json with representative fields (e.g., serverName, version, host,
port, maxPlayers, region, maintenanceWindow, tags, createdAt) so consumers see
the expected shape, and mirror similar example entries into ServerLive.json if
both are intended as samples; otherwise, add a short comment in the file or
repository README indicating the empty object is intentional to avoid confusion.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 259365e4-ee7d-4f57-a4fb-5e74506ad5c8
📒 Files selected for processing (16)
quick-start/docker-compose.ymlquick-start/grpc-samples/inferflow/InferPairWise.jsonquick-start/grpc-samples/inferflow/InferPointWise.jsonquick-start/grpc-samples/inferflow/RetrieveModelScore.jsonquick-start/grpc-samples/numerix/Compute.jsonquick-start/grpc-samples/onfs/PersistFeatures.jsonquick-start/grpc-samples/onfs/RetrieveDecodedResult.jsonquick-start/grpc-samples/onfs/RetrieveFeatures.jsonquick-start/grpc-samples/predator/ModelInfer.jsonquick-start/grpc-samples/predator/ServerLive.jsonquick-start/grpc-samples/predator/ServerMetadata.jsonquick-start/grpc-samples/skye/getCandidateEmbeddingScores.jsonquick-start/grpc-samples/skye/getEmbeddingsForCandidates.jsonquick-start/grpc-samples/skye/getSimilarCandidates.jsonquick-start/nginx/index.htmlquick-start/start.sh
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@quick-start/docker-compose.yml`:
- Around line 978-1010: The grpcui startup in the docker-compose grpc service
hardcodes -import-path entries (/protos/onfs, /protos/numerix,
/protos/inferflow, /protos/skye, /protos/predator) causing startup failure when
some source dirs are not copied; update setup_workspace() to either 1) detect
which proto directories were actually copied and generate the grpcui command
args dynamically (only include -import-path and -proto flags for existing
/protos/* dirs and their .proto files), or 2) validate presence of all required
proto dirs before enabling START_GRPCUI and fail fast with a clear error; ensure
the change touches the code that constructs the grpcui command (the
docker-compose generation or template) and references the START_GRPCUI toggle so
grpcui is only started with valid proto paths.
In `@quick-start/start.sh`:
- Around line 103-123: The script currently runs unprivileged `docker info`
probes immediately after installation which fail if the current user lacks
docker group membership; update the install blocks and the daemon-ready probe to
handle this: in the curl-based install (where `usermod -aG docker "$USER"` is
called) either exit after install with a clear message to log out/in instead of
probing, or keep the probe but run it with `sudo docker info`; for the
apt-get/dnf/yum branches add the same `sudo usermod -aG docker "$USER"` step (or
explicitly choose to require relogin and exit) so group membership is
consistent; finally change the daemon start/retry loop that currently calls
`docker info` without privileges to use `sudo docker info` (or fail fast and
instruct the user to re-open their shell) so permission errors no longer cause
false negatives when checking daemon readiness (`sudo systemctl start docker`
and the subsequent probe).
- Around line 375-378: The fallback block using "location /" currently uses
"return 12" which is not a valid HTTP status and won't communicate a gRPC
UNIMPLEMENTED to gRPC clients; replace this pattern with an error_page +
internal handler that returns HTTP 204 with Content-Type application/grpc and
sets grpc-status and grpc-message headers (e.g., add_header grpc-status 12 and
grpc-message "unimplemented" always) so gRPC clients receive the gRPC status;
update the "location /" to pass to the backend or trigger the error_page and add
a new internal location (e.g., `@grpc_unimplemented`) that sets default_type
application/grpc, the grpc headers, and returns 204 instead of using "return
12".
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 71505b5b-2bc0-4ea6-adef-00b76562d640
📒 Files selected for processing (2)
quick-start/docker-compose.ymlquick-start/start.sh
| command: | ||
| - -plaintext | ||
| - -port | ||
| - "8080" | ||
| - -bind | ||
| - 0.0.0.0 | ||
| - -import-path | ||
| - /protos/onfs | ||
| - -import-path | ||
| - /protos/numerix | ||
| - -import-path | ||
| - /protos/inferflow | ||
| - -import-path | ||
| - /protos/skye | ||
| - -import-path | ||
| - /protos/predator | ||
| - -proto | ||
| - retrieve.proto | ||
| - -proto | ||
| - persist.proto | ||
| - -proto | ||
| - numerix.proto | ||
| - -proto | ||
| - inferflow.proto | ||
| - -proto | ||
| - predict.proto | ||
| - -proto | ||
| - skye.proto | ||
| - -proto | ||
| - grpc_service.proto | ||
| - -proto | ||
| - health.proto | ||
| - grpc-proxy:9000 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the docker-compose.yml file around the grpcui service
wc -l quick-start/docker-compose.ymlRepository: Meesho/BharatMLStack
Length of output: 99
🏁 Script executed:
# Check the grpcui service configuration
sed -n '978,1010p' quick-start/docker-compose.ymlRepository: Meesho/BharatMLStack
Length of output: 700
🏁 Script executed:
# Get more context around the grpcui service definition
sed -n '950,1025p' quick-start/docker-compose.ymlRepository: Meesho/BharatMLStack
Length of output: 2094
🏁 Script executed:
# Now let's examine the start.sh file around the proto copying section
wc -l quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 89
🏁 Script executed:
# Check the workspace setup in start.sh
sed -n '260,300p' quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 1628
🏁 Script executed:
# Check if grpcui service has any conditional logic or restart behavior
sed -n '972,1025p' quick-start/docker-compose.yml | grep -A5 -B5 "depends_on\|condition"Repository: Meesho/BharatMLStack
Length of output: 225
🏁 Script executed:
# Check the full docker-compose structure for any SELECTED_SERVICES logic
grep -n "SELECTED_SERVICES\|grpcui" quick-start/docker-compose.ymlRepository: Meesho/BharatMLStack
Length of output: 226
🏁 Script executed:
# Check start.sh for any logic that conditionally enables/disables services
grep -n "SELECTED_SERVICES\|grpcui" quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 2001
🏁 Script executed:
# Check if there's any logic that conditionally adds grpcui to docker-compose
grep -B5 -A5 "grpcui" quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 2113
🏁 Script executed:
# Check where START_GRPCUI is set and if it has any conditional logic
grep -n "START_GRPCUI" quick-start/start.sh | head -20Repository: Meesho/BharatMLStack
Length of output: 391
🏁 Script executed:
# Get more context around START_GRPCUI assignment
grep -B10 -A10 "START_GRPCUI=" quick-start/start.sh | head -40Repository: Meesho/BharatMLStack
Length of output: 1275
🏁 Script executed:
# Get context for each START_GRPCUI=true assignment to understand when grpcui is enabled
sed -n '690,700p' quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 484
🏁 Script executed:
# Check around line 695 (ONFS)
sed -n '690,705p' quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 622
🏁 Script executed:
# Check all service selection blocks to understand the full picture
grep -B5 "START_GRPCUI=true" quick-start/start.sh | grep -A5 "START_.*=true"Repository: Meesho/BharatMLStack
Length of output: 1714
🏁 Script executed:
# Get the actual service selection logic in custom_selection function
sed -n '680,770p' quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 3169
grpcui command hard-codes proto paths that may not exist when services are partially selected.
START_GRPCUI is enabled whenever any gRPC service is selected, but setup_workspace() only copies proto directories when their source paths exist. If a user selects ONFS and Numerix but Skye's source code is absent, grpcui will still try to load all five -import-path directories and fail at startup instead of gracefully omitting Skye from the UI. Dynamically build the proto arguments based on which directories were actually copied, or fail fast during setup if required proto paths are missing when grpcui is about to start.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@quick-start/docker-compose.yml` around lines 978 - 1010, The grpcui startup
in the docker-compose grpc service hardcodes -import-path entries (/protos/onfs,
/protos/numerix, /protos/inferflow, /protos/skye, /protos/predator) causing
startup failure when some source dirs are not copied; update setup_workspace()
to either 1) detect which proto directories were actually copied and generate
the grpcui command args dynamically (only include -import-path and -proto flags
for existing /protos/* dirs and their .proto files), or 2) validate presence of
all required proto dirs before enabling START_GRPCUI and fail fast with a clear
error; ensure the change touches the code that constructs the grpcui command
(the docker-compose generation or template) and references the START_GRPCUI
toggle so grpcui is only started with valid proto paths.
| Linux) | ||
| echo "🐧 Linux detected." | ||
| if command -v curl &> /dev/null; then | ||
| echo " Installing Docker Engine via official install script..." | ||
| curl -fsSL https://get.docker.com | sh | ||
| # Add current user to docker group so future commands don't need sudo | ||
| sudo usermod -aG docker "$USER" 2>/dev/null || true | ||
| echo "✅ Docker installed." | ||
| echo "⚠️ NOTE: Log out and back in for the docker group to take effect." | ||
| elif command -v apt-get &> /dev/null; then | ||
| sudo apt-get update -y && sudo apt-get install -y docker.io | ||
| elif command -v dnf &> /dev/null; then | ||
| sudo dnf install -y docker | ||
| elif command -v yum &> /dev/null; then | ||
| sudo yum install -y docker | ||
| else | ||
| echo "❌ Could not detect a supported package manager." | ||
| echo "👉 Please install Docker manually: https://docs.docker.com/engine/install/" | ||
| exit 1 | ||
| fi | ||
| ;; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
head -n 200 quick-start/start.sh | tail -n +100Repository: Meesho/BharatMLStack
Length of output: 3858
🏁 Script executed:
# Let me check the full context around the docker info call and group membership handling
sed -n '135,200p' quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 2501
🏁 Script executed:
# Check if there's any sudo docker handling in the daemon check for Linux
sed -n '135,200p' quick-start/start.sh | grep -A5 -B5 "docker info"Repository: Meesho/BharatMLStack
Length of output: 1217
🏁 Script executed:
# Check the complete Docker installation flow and what happens immediately after
sed -n '103,145p' quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 1854
Fresh Linux installs fail the Docker daemon check due to permission issues.
After Docker installation on Linux, the script immediately calls docker info in the same shell session. However:
-
curl-based install (lines 106-111): Adds user to docker group via
sudo usermod -aG docker "$USER", but the script itself warns "Log out and back in for the docker group to take effect." This contradicts the immediatedocker infocheck at line 135, which will fail with permission denied. -
apt-get/dnf/yum installs (lines 112-120): Do not add the user to the docker group at all, so the subsequent
docker infocalls will always fail with permission denied. -
Daemon start retry loop (lines 170-177): Even after starting the daemon with
sudo systemctl start docker, the loop checksdocker infowithoutsudo, which fails if the user lacks docker group permissions.
Either exit after installation and ask the user to reopen their shell, or use sudo docker info in the probe and subsequent daemon-ready checks to handle unprivileged users.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@quick-start/start.sh` around lines 103 - 123, The script currently runs
unprivileged `docker info` probes immediately after installation which fail if
the current user lacks docker group membership; update the install blocks and
the daemon-ready probe to handle this: in the curl-based install (where `usermod
-aG docker "$USER"` is called) either exit after install with a clear message to
log out/in instead of probing, or keep the probe but run it with `sudo docker
info`; for the apt-get/dnf/yum branches add the same `sudo usermod -aG docker
"$USER"` step (or explicitly choose to require relogin and exit) so group
membership is consistent; finally change the daemon start/retry loop that
currently calls `docker info` without privileges to use `sudo docker info` (or
fail fast and instruct the user to re-open their shell) so permission errors no
longer cause false negatives when checking daemon readiness (`sudo systemctl
start docker` and the subsequent probe).
| # Catch-all: return a gRPC UNIMPLEMENTED status | ||
| location / { | ||
| return 12 "No gRPC service matched this path"; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's locate and examine the file
find . -name "start.sh" -path "*/quick-start/*" -type fRepository: Meesho/BharatMLStack
Length of output: 86
🏁 Script executed:
# Once we find the file, let's examine the relevant lines with context
sed -n '370,385p' quick-start/start.shRepository: Meesho/BharatMLStack
Length of output: 594
🌐 Web query:
nginx return directive valid status codes syntax documentation
💡 Result:
From the official ngx_http_rewrite_module docs, the return directive syntax is: [1]
return code [text];
return code URL;
return URL;Valid status codes / how they’re interpreted:
codecan be any numeric HTTP status code (NGINX will “return the specified code”). If you provide a second parameter and the code is not a redirect code, that second parameter is treated as the response bodytext. [1]- If you provide a redirect
URL, NGINX treats it as a redirect only for: 301, 302, 303, 307, 308. (307 and 308 became “treated as redirect” starting in specific NGINX versions.) [1] - Special NGINX-only code:
444closes the connection without sending a response header. [1] return URL;(URL as the only parameter) is a shorthand for a 302 temporary redirect, and the URL should start withhttp://,https://, or$scheme. [1]
Source(s)
[1] NGINX documentation — Module ngx_http_rewrite_module (return directive). (nginx.org)
Citations:
🌐 Web query:
nginx grpc status code error handling return proper syntax
💡 Result:
To return a gRPC-compliant error from NGINX (instead of an HTTP error page), use an error_page that jumps to an internal location which returns HTTP 204 plus application/grpc and the grpc-status / grpc-message headers:
location /my.Service/ {
grpc_pass grpc://upstream_grpc;
error_page 502 = /error502grpc; # example: no upstream available / bad gateway
}
location = /error502grpc {
internal;
default_type application/grpc;
add_header grpc-status 14; # UNAVAILABLE
add_header grpc-message "unavailable";
return 204;
}This is the canonical NGINX pattern for “proper” gRPC error responses (gRPC uses trailers for status, and NGINX uses this 204 + application/grpc approach to produce a gRPC-compliant error). [1]
If you also need to intercept upstream responses with HTTP status >= 300 (so they can be handled by error_page), enable:
grpc_intercept_errors on;NGINX documents grpc_intercept_errors exactly for this purpose (intercepting upstream gRPC-server responses with codes ≥ 300 and routing them to error_page). [2]
For choosing the right grpc-status value, use the standard gRPC status codes (e.g., 14 = UNAVAILABLE, 16 = UNAUTHENTICATED, etc.). [3]
Sources: [1] NGINX gRPC support blog config example, [2] ngx_http_grpc_module (grpc_intercept_errors), [3] gRPC status codes reference.
🌐 Web query:
nginx gRPC UNIMPLEMENTED status code how to return properly
💡 Result:
To return gRPC UNIMPLEMENTED (code 12) from NGINX, you must generate a valid gRPC-over-HTTP/2 response: HTTP status 204 with grpc-status: 12 (and optionally grpc-message) set, typically via an internal error_page handler. NGINX can’t use return 12; because 12 is a gRPC status (sent via headers/trailers), not an HTTP status. [1][2]
Example (return UNIMPLEMENTED for an HTTP 404, e.g., unknown RPC path you route to NGINX):
location / {
grpc_pass grpc://grpc_backend;
grpc_intercept_errors on;
error_page 404 = `@grpc_unimplemented`;
}
location `@grpc_unimplemented` {
internal;
default_type application/grpc;
add_header grpc-status 12 always;
add_header grpc-message "unimplemented" always;
return 204;
}Notes:
grpc_intercept_errors on;is what lets NGINX replace upstream HTTP errors (>=300) with yourerror_pagegRPC response. [2]UNIMPLEMENTEDis gRPC status 12 by spec. [3]- Don’t confuse this with
health_check ... grpc_status=12;—thatgrpc_statusparameter is for health checks, not for returning responses to clients. [1]
Sources
- NGINX docs: gRPC health checks and
grpc_status=12(UNIMPLEMENTED) for HC expectations. [1] - NGINX
grpc_intercept_errorsdirective (for usingerror_pagewith gRPC). [2] - gRPC official status code reference (
UNIMPLEMENTED = 12). [3]
References:
[1] (docs.nginx.com)
[2] (nginx.org)
[3] (grpc.io)
Citations:
- 1: https://docs.nginx.com/nginx/admin-guide/load-balancer/grpc-health-check/?utm_source=openai
- 2: https://nginx.org/r/grpc_ssl_certificate
- 3: https://grpc.io/docs/guides/status-codes/?utm_source=openai
return 12 is not a valid HTTP status code and will not work for gRPC clients.
This fallback attempts to use the gRPC UNIMPLEMENTED code as an HTTP status, but gRPC status codes (0–16) are not HTTP status codes (100–599). gRPC clients expect the status code to be conveyed via grpc-status and grpc-message response headers.
Use an error_page handler that returns HTTP 204 with proper gRPC headers:
Correct pattern
location / {
grpc_pass grpc://backend;
grpc_intercept_errors on;
error_page 404 = `@grpc_unimplemented`;
}
location `@grpc_unimplemented` {
internal;
default_type application/grpc;
add_header grpc-status 12 always;
add_header grpc-message "unimplemented" always;
return 204;
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@quick-start/start.sh` around lines 375 - 378, The fallback block using
"location /" currently uses "return 12" which is not a valid HTTP status and
won't communicate a gRPC UNIMPLEMENTED to gRPC clients; replace this pattern
with an error_page + internal handler that returns HTTP 204 with Content-Type
application/grpc and sets grpc-status and grpc-message headers (e.g., add_header
grpc-status 12 and grpc-message "unimplemented" always) so gRPC clients receive
the gRPC status; update the "location /" to pass to the backend or trigger the
error_page and add a new internal location (e.g., `@grpc_unimplemented`) that sets
default_type application/grpc, the grpc headers, and returns 204 instead of
using "return 12".
| @@ -0,0 +1,15 @@ | |||
| { | |||
| "entity": "product", | |||
| "candidateIds": ["product_101", "product_202", "product_303"], | |||
There was a problem hiding this comment.
here in the request only thing should be paseed, for now we can keep it embedding and remove candidate id. As at any pont of time user can search using either embedding or caniddtae id.
2 participants
🔁 Pull Request Template – BharatMLStack
Context:
This eases out the quick start process by installing/starting docker itself and also exposes grpc web UI for API testing
Describe your changes:
in the quick-start module
Testing:
By running in local and verifying grpc request body with metadata
Monitoring:
NA
Rollback plan
NA
Checklist before requesting a review
📂 Modules Affected
horizon(Real-time systems / networking)online-feature-store(Feature serving infra)trufflebox-ui(Admin panel / UI)infra(Docker, CI/CD, GCP/AWS setup)docs(Documentation updates)___________✅ Type of Change
___________📊 Benchmark / Metrics (if applicable)
Summary by CodeRabbit
Release Notes