ENG-1945: add liveness check that is less sensitive

[LucioFranco]

Note

Low Risk
Low risk: adds a new read-only endpoint and updates WebApp mount-path validation; impact is limited to health probing behavior and potential mount path conflicts for apps using /liveness.

Overview
Adds a new GET /liveness endpoint on the local webserver as a lightweight liveness probe that only checks the Consumption API’s internal health endpoint (with a short timeout) and avoids validating external dependencies covered by GET /health.

Updates the route listing/help output to include /liveness, and reserves /liveness as a forbidden WebApp mount prefix in both the Python and TypeScript SDKs to prevent route collisions.

^{Written by Cursor Bugbot for commit 9d6bb6a. This will update automatically on new commits. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs-v2	Ready	Preview, Comment	Feb 4, 2026 5:38pm

[linear]

ENG-1945 Moose healthchecks are too sensitive to transient failures

[LucioFranco]

• ENG-1945: add liveness check that is less sensitive #3452 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[coderabbitai]

Summary by CodeRabbit

• New Features

  • Added a liveness probe endpoint that monitors service health status, returning 200 OK when healthy or 503 Service Unavailable when unhealthy.

• Chores

  • Reserved the "/liveness" path across all mount configurations to prevent conflicts.

Walkthrough

The PR introduces a liveness probe endpoint for the CLI webserver that monitors Consumption API health when the feature is enabled. The endpoint queries the health status with a 2-second timeout and returns HTTP 200 or 503 based on health state. Additionally, "/liveness" is added to reserved mount paths in both Python and TypeScript SDKs to prevent user applications from mounting at that path.

Changes

Cohort / File(s)	Summary
CLI Liveness Probe apps/framework-cli/src/cli/local_webserver.rs	New GET /liveness endpoint queries Consumption API health endpoint at localhost with 2-second timeout. Returns JSON with "healthy" and "unhealthy" lists; responds 200 OK if healthy, 503 if unhealthy. Includes error handling for client creation and request failures. Endpoint integrated into main router and route listing output.
Reserved Mount Paths packages/py-moose-lib/moose_lib/dmv2/web_app.py, packages/ts-moose-lib/src/dmv2/sdk/webApp.ts	Added "/liveness" to RESERVED_MOUNT_PATHS lists in both Python and TypeScript SDKs to prevent user applications from mounting WebApps at or under this path.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

Poem

🔍 A liveness probe takes flight,
Checking health with timeout's might,
Reserved paths kept clean and tight,
Transient failures lose their bite. ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title clearly identifies the main change: adding a liveness check endpoint that is less sensitive to transient failures.
Description check	✅ Passed	Description directly relates to the changeset, explaining the new /liveness endpoint, its behavior, and SDK updates.
Linked Issues check	✅ Passed	Changes meet the objective of ENG-1945: a new less-sensitive liveness probe endpoint reduces healthcheck sensitivity to transient failures.
Out of Scope Changes check	✅ Passed	All changes directly support the objective: the liveness endpoint implementation and reserved mount path updates in SDKs are in scope.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-probes

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apps/framework-cli/src/cli/local_webserver.rs`:
- Around line 918-983: The /live handler (live_route) currently builds a new
reqwest::Client per probe (the client variable) which prevents connection
pooling; instead reuse the existing shared client on the Project (e.g.,
project.http_client or project.shared_reqwest_client) and apply a per-request
timeout on the request builder with .timeout(Duration::from_secs(2)) before
.send().await; remove the Client::builder() block and its error branch, but keep
the same warning/response behavior if the shared client is absent (log a warning
and return SERVICE_UNAVAILABLE with the same JSON) or if the request
fails/returns non-success (retain the warn! messages and healthy/unhealthy
logic).

📜 Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 3522f89 and 2eafb03.

📒 Files selected for processing (1)

• apps/framework-cli/src/cli/local_webserver.rs

🧰 Additional context used

📓 Path-based instructions (3)

**/*.rs

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Run cargo clippy to ensure Rust code passes Clippy's linting standards before each commit

**/*.rs: Use thiserror with #[derive(thiserror::Error)] for error handling in Rust; define errors near the fallibility unit, never use anyhow::Result
Use snake_case for functions and variables, PascalCase for types and traits, SCREAMING_SNAKE_CASE for constants in Rust
Place constants in constants.rs at the appropriate module level in Rust
Use tuple structs with validation constructors (newtypes) for Rust type safety (e.g., struct UserId(String))
Write inline tests with #[cfg(test)] modules in Rust
Documentation is required for all public APIs in Rust
Run cargo clippy --all-targets -- -D warnings before committing Rust code; no warnings allowed

Files:

• apps/framework-cli/src/cli/local_webserver.rs

apps/framework-cli/**/*.rs

📄 CodeRabbit inference engine (apps/framework-cli/AGENTS.md)

apps/framework-cli/**/*.rs: Always run cargo clippy --all-targets -- -D warnings before commits; fix all warnings - no Clippy warnings may remain (treat warnings as errors)
Use rustfmt --edition 2021 for consistent formatting
Write meaningful names for functions, variables, and types
Document all public APIs and breaking changes
Use thiserror crate instead of anyhow::Result for error handling
Define errors near their unit of fallibility (no global Error types)
Use #[derive(thiserror::Error)] with #[error()] messages for error definitions
Define newtypes as tuple structs: struct UserId(u64);
Add validation constructors for newtypes: UserId::new(id: u64) -> Result<Self, Error>
Derive standard traits for newtypes: #[derive(Debug, Clone, PartialEq)]
Implement From/TryFrom for newtype conversions
Use derive_more or nutype to reduce newtype boilerplate
Use const for static values (prefer over static)
Use UPPER_SNAKE_CASE naming for constants
Scope constant visibility with preference: pub(crate) > pub(super) > pub
Group related constants together
Write unit tests for all public functions
Test error conditions and edge cases

Files:

• apps/framework-cli/src/cli/local_webserver.rs

**/framework-cli/src/**

⚙️ CodeRabbit configuration file

**/framework-cli/src/**: When reviewing changes to Moose CLI:

1. Check if any user-facing changes were made (commands, flags, configs, apis, etc)
2. If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
3. If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
4. In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.

Files:

• apps/framework-cli/src/cli/local_webserver.rs

🧠 Learnings (1)

📚 Learning: 2025-12-16T23:09:10.917Z

Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-cli/AGENTS.md:0-0
Timestamp: 2025-12-16T23:09:10.917Z
Learning: Applies to apps/framework-cli/**/*.rs : Document all public APIs and breaking changes

Applied to files:

• apps/framework-cli/src/cli/local_webserver.rs

⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)

• GitHub Check: Test E2E TypeScript Tests Template (Node 22, npm)
• GitHub Check: Test E2E TypeScript Tests Template (Node 24, npm)
• GitHub Check: Test E2E Python Tests Template (Python 3.12)
• GitHub Check: Test E2E Python Tests Template (Python 3.13)
• GitHub Check: Test E2E TypeScript Tests Template (Node 20, npm)

🔇 Additional comments (2)

apps/framework-cli/src/cli/local_webserver.rs (2)

918-983: Confirm clippy + rustfmt were run.

Please confirm cargo clippy --all-targets -- -D warnings and rustfmt --edition 2021 were executed for this change.
As per coding guidelines: “apps/framework-cli/**/*.rs: Always run cargo clippy --all-targets -- -D warnings before commits; fix all warnings - no Clippy warnings may remain (treat warnings as errors) ... Use rustfmt --edition 2021 for consistent formatting.”

---

2268-2272: Ensure Moose CLI docs mention the new /live probe.

Please verify the docs under apps/framework-docs-v2/content were updated for this new endpoint (or add them if missing).
As per coding guidelines: “When reviewing changes to Moose CLI: 1. Check if any user-facing changes were made ... 2. If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content ...”

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apps/framework-cli/src/cli/local_webserver.rs`:
- Around line 918-921: Documentation is missing explicit mappings of Kubernetes
probes to the server endpoints; update metrics.mdx or
deploying-on-kubernetes.mdx to list /liveness (implemented by live_route) as the
Liveness probe, /ready (implemented by ready_route) as the Readiness probe, and
/health (health_route or existing health handler) as the Startup/overall health
probe, and add brief guidance when to use each (Startup = initial boot check,
Readiness = traffic readiness, Liveness = detect deadlocks/unresponsive
process). Include the endpoint paths, the corresponding handler names
(live_route, ready_route, health_route), and one-line examples of which probe
type to configure in Kubernetes manifest
readinessProbe/livenessProbe/startupProbe.

📜 Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 2eafb03 and 9d6bb6a.

📒 Files selected for processing (3)

• apps/framework-cli/src/cli/local_webserver.rs
• packages/py-moose-lib/moose_lib/dmv2/web_app.py
• packages/ts-moose-lib/src/dmv2/sdk/webApp.ts

🧰 Additional context used

📓 Path-based instructions (8)

**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

**/*.py: Follow PEP 8 style guide in Python; use snake_case for functions/variables, PascalCase for classes, UPPER_SNAKE_CASE for constants
Format Python code with Black using line-length 88; auto-formats on commit via Husky + lint-staged
Use type hints for function signatures and public APIs in Python

Files:

• packages/py-moose-lib/moose_lib/dmv2/web_app.py

**/py-moose-lib/moose_lib/**/*.py

⚙️ CodeRabbit configuration file

**/py-moose-lib/moose_lib/**/*.py: When reviewing changes to python moose lib:

1. Check if any public apis were changed (class, method, type, config, etc)
2. If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
3. If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
4. In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.

Files:

• packages/py-moose-lib/moose_lib/dmv2/web_app.py

**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Run linting checks before submitting PRs for TypeScript/JavaScript code

**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g., _unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier using experimentalTernaries: true; auto-formats on commit via Husky + lint-staged

Files:

• packages/ts-moose-lib/src/dmv2/sdk/webApp.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs

Files:

• packages/ts-moose-lib/src/dmv2/sdk/webApp.ts

**/ts-moose-lib/src/**/*.ts

⚙️ CodeRabbit configuration file

**/ts-moose-lib/src/**/*.ts: When reviewing changes to typescript moose lib:

1. Check if any public apis were changed (class, method, type, config, etc).
2. If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content.
3. If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
4. In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.

Files:

• packages/ts-moose-lib/src/dmv2/sdk/webApp.ts

**/*.rs

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Run cargo clippy to ensure Rust code passes Clippy's linting standards before each commit

**/*.rs: Use thiserror with #[derive(thiserror::Error)] for error handling in Rust; define errors near the fallibility unit, never use anyhow::Result
Use snake_case for functions and variables, PascalCase for types and traits, SCREAMING_SNAKE_CASE for constants in Rust
Place constants in constants.rs at the appropriate module level in Rust
Use tuple structs with validation constructors (newtypes) for Rust type safety (e.g., struct UserId(String))
Write inline tests with #[cfg(test)] modules in Rust
Documentation is required for all public APIs in Rust
Run cargo clippy --all-targets -- -D warnings before committing Rust code; no warnings allowed

Files:

• apps/framework-cli/src/cli/local_webserver.rs

apps/framework-cli/**/*.rs

📄 CodeRabbit inference engine (apps/framework-cli/AGENTS.md)

apps/framework-cli/**/*.rs: Always run cargo clippy --all-targets -- -D warnings before commits; fix all warnings - no Clippy warnings may remain (treat warnings as errors)
Use rustfmt --edition 2021 for consistent formatting
Write meaningful names for functions, variables, and types
Document all public APIs and breaking changes
Use thiserror crate instead of anyhow::Result for error handling
Define errors near their unit of fallibility (no global Error types)
Use #[derive(thiserror::Error)] with #[error()] messages for error definitions
Define newtypes as tuple structs: struct UserId(u64);
Add validation constructors for newtypes: UserId::new(id: u64) -> Result<Self, Error>
Derive standard traits for newtypes: #[derive(Debug, Clone, PartialEq)]
Implement From/TryFrom for newtype conversions
Use derive_more or nutype to reduce newtype boilerplate
Use const for static values (prefer over static)
Use UPPER_SNAKE_CASE naming for constants
Scope constant visibility with preference: pub(crate) > pub(super) > pub
Group related constants together
Write unit tests for all public functions
Test error conditions and edge cases

Files:

• apps/framework-cli/src/cli/local_webserver.rs

**/framework-cli/src/**

⚙️ CodeRabbit configuration file

**/framework-cli/src/**: When reviewing changes to Moose CLI:

1. Check if any user-facing changes were made (commands, flags, configs, apis, etc)
2. If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
3. If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
4. In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.

Files:

• apps/framework-cli/src/cli/local_webserver.rs

🧠 Learnings (2)

📚 Learning: 2026-01-20T15:49:26.025Z

Learnt from: 514Ben
Repo: 514-labs/moosestack PR: 3150
File: packages/py-moose-lib/moose_lib/dmv2/materialized_view.py:35-35
Timestamp: 2026-01-20T15:49:26.025Z
Learning: In the Python moose library (packages/py-moose-lib), prefer typing.Union[X, Y] syntax over PEP 604's X | Y for type annotations. Use Union when you want to explicitly convey a union in the type system, especially if readability or tooling friendliness (e.g., older type checkers) is a consideration. Reserve X | Y for simple, modern type hints where you want concise syntax and are sure the project’s type checker version supports PEP 604 without issues.

Applied to files:

• packages/py-moose-lib/moose_lib/dmv2/web_app.py

📚 Learning: 2025-12-16T23:09:10.917Z

Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-cli/AGENTS.md:0-0
Timestamp: 2025-12-16T23:09:10.917Z
Learning: Applies to apps/framework-cli/**/*.rs : Document all public APIs and breaking changes

Applied to files:

• apps/framework-cli/src/cli/local_webserver.rs

⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)

• GitHub Check: Test E2E Backward Compatibility - TypeScript (Node 20)
• GitHub Check: Test E2E TypeScript Default Template (Node 24, pnpm-9)
• GitHub Check: Test E2E TypeScript Default Template (Node 22, pnpm-9)
• GitHub Check: Test E2E TypeScript Tests Template (Node 20, npm)
• GitHub Check: Test E2E TypeScript Default Template (Node 20, pnpm-10)
• GitHub Check: Test E2E TypeScript Default Template (Node 20, pnpm-9)
• GitHub Check: Test E2E TypeScript Tests Template (Node 24, npm)
• GitHub Check: Test E2E TypeScript Default Template (Node 20, npm)
• GitHub Check: Test E2E TypeScript Default Template (Node 22, pnpm-10)
• GitHub Check: Test E2E TypeScript Tests Template (Node 22, npm)
• GitHub Check: Test E2E Python Tests Template (Python 3.13)
• GitHub Check: Test E2E Python Tests Template (Python 3.12)
• GitHub Check: Test E2E Python Default Template (Python 3.12)

🔇 Additional comments (4)

packages/py-moose-lib/moose_lib/dmv2/web_app.py (1)

20-20: LGTM!

Consistent with the new /liveness endpoint and follows the existing reserved paths pattern.

packages/ts-moose-lib/src/dmv2/sdk/webApp.ts (1)

32-32: LGTM!

Maintains consistency with Python SDK and aligns with the new backend endpoint.

apps/framework-cli/src/cli/local_webserver.rs (2)

1966-1966: LGTM!

Routing follows the established pattern for health check endpoints.

---

2268-2272: LGTM!

Description accurately conveys the narrower scope compared to /health.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apps/framework-cli/src/cli/local_webserver.rs`:
- Around line 918-983: Add a new docs entry for the /liveness endpoint
(implemented by live_route) under the Health Monitoring section: explain that
/liveness is a lightweight probe that only checks the Consumption API (versus
/health which performs full system checks), show the JSON response schema with
"healthy" and "unhealthy" arrays and an example response, and include guidance
on when to use /liveness vs /health for monitoring and alerting.

📜 Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 3522f89 and 9d6bb6a.

📒 Files selected for processing (3)

• apps/framework-cli/src/cli/local_webserver.rs
• packages/py-moose-lib/moose_lib/dmv2/web_app.py
• packages/ts-moose-lib/src/dmv2/sdk/webApp.ts

🧰 Additional context used

📓 Path-based instructions (8)

**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Run linting checks before submitting PRs for TypeScript/JavaScript code

**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g., _unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier using experimentalTernaries: true; auto-formats on commit via Husky + lint-staged

Files:

• packages/ts-moose-lib/src/dmv2/sdk/webApp.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs

Files:

• packages/ts-moose-lib/src/dmv2/sdk/webApp.ts

**/ts-moose-lib/src/**/*.ts

⚙️ CodeRabbit configuration file

**/ts-moose-lib/src/**/*.ts: When reviewing changes to typescript moose lib:

1. Check if any public apis were changed (class, method, type, config, etc).
2. If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content.
3. If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
4. In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.

Files:

• packages/ts-moose-lib/src/dmv2/sdk/webApp.ts

**/*.rs

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Run cargo clippy to ensure Rust code passes Clippy's linting standards before each commit

**/*.rs: Use thiserror with #[derive(thiserror::Error)] for error handling in Rust; define errors near the fallibility unit, never use anyhow::Result
Use snake_case for functions and variables, PascalCase for types and traits, SCREAMING_SNAKE_CASE for constants in Rust
Place constants in constants.rs at the appropriate module level in Rust
Use tuple structs with validation constructors (newtypes) for Rust type safety (e.g., struct UserId(String))
Write inline tests with #[cfg(test)] modules in Rust
Documentation is required for all public APIs in Rust
Run cargo clippy --all-targets -- -D warnings before committing Rust code; no warnings allowed

Files:

• apps/framework-cli/src/cli/local_webserver.rs

apps/framework-cli/**/*.rs

📄 CodeRabbit inference engine (apps/framework-cli/AGENTS.md)

apps/framework-cli/**/*.rs: Always run cargo clippy --all-targets -- -D warnings before commits; fix all warnings - no Clippy warnings may remain (treat warnings as errors)
Use rustfmt --edition 2021 for consistent formatting
Write meaningful names for functions, variables, and types
Document all public APIs and breaking changes
Use thiserror crate instead of anyhow::Result for error handling
Define errors near their unit of fallibility (no global Error types)
Use #[derive(thiserror::Error)] with #[error()] messages for error definitions
Define newtypes as tuple structs: struct UserId(u64);
Add validation constructors for newtypes: UserId::new(id: u64) -> Result<Self, Error>
Derive standard traits for newtypes: #[derive(Debug, Clone, PartialEq)]
Implement From/TryFrom for newtype conversions
Use derive_more or nutype to reduce newtype boilerplate
Use const for static values (prefer over static)
Use UPPER_SNAKE_CASE naming for constants
Scope constant visibility with preference: pub(crate) > pub(super) > pub
Group related constants together
Write unit tests for all public functions
Test error conditions and edge cases

Files:

• apps/framework-cli/src/cli/local_webserver.rs

**/framework-cli/src/**

⚙️ CodeRabbit configuration file

**/framework-cli/src/**: When reviewing changes to Moose CLI:

1. Check if any user-facing changes were made (commands, flags, configs, apis, etc)
2. If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
3. If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
4. In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.

Files:

• apps/framework-cli/src/cli/local_webserver.rs

**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

**/*.py: Follow PEP 8 style guide in Python; use snake_case for functions/variables, PascalCase for classes, UPPER_SNAKE_CASE for constants
Format Python code with Black using line-length 88; auto-formats on commit via Husky + lint-staged
Use type hints for function signatures and public APIs in Python

Files:

• packages/py-moose-lib/moose_lib/dmv2/web_app.py

**/py-moose-lib/moose_lib/**/*.py

⚙️ CodeRabbit configuration file

**/py-moose-lib/moose_lib/**/*.py: When reviewing changes to python moose lib:

1. Check if any public apis were changed (class, method, type, config, etc)
2. If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
3. If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
4. In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.

Files:

• packages/py-moose-lib/moose_lib/dmv2/web_app.py

🧠 Learnings (1)

📚 Learning: 2026-01-20T15:49:26.025Z

Learnt from: 514Ben
Repo: 514-labs/moosestack PR: 3150
File: packages/py-moose-lib/moose_lib/dmv2/materialized_view.py:35-35
Timestamp: 2026-01-20T15:49:26.025Z
Learning: In the Python moose library (packages/py-moose-lib), prefer typing.Union[X, Y] syntax over PEP 604's X | Y for type annotations. Use Union when you want to explicitly convey a union in the type system, especially if readability or tooling friendliness (e.g., older type checkers) is a consideration. Reserve X | Y for simple, modern type hints where you want concise syntax and are sure the project’s type checker version supports PEP 604 without issues.

Applied to files:

• packages/py-moose-lib/moose_lib/dmv2/web_app.py

🔇 Additional comments (4)

packages/py-moose-lib/moose_lib/dmv2/web_app.py (1)

14-24: LGTM!

Reserved path list correctly updated to include /liveness, consistent with the new liveness probe endpoint. No public API changes, so no documentation update needed.

packages/ts-moose-lib/src/dmv2/sdk/webApp.ts (1)

26-36: LGTM!

Reserved path list correctly synchronized with Python SDK. Internal constant, no public API change.

apps/framework-cli/src/cli/local_webserver.rs (2)

1966-1967: LGTM!

Route wiring is correct and consistent with the reserved path additions.

---

2268-2272: LGTM!

Route listing correctly includes the new liveness probe with accurate description.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

[LucioFranco]

Merge activity

• Feb 4, 6:45 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Feb 4, 6:45 PM UTC: Graphite couldn't merge this PR because it failed for an unknown reason (This repository has GitHub's merge queue enabled. Please configure the GitHub merge queue integration in Graphite settings.).