Enhance static report generation guide with new PDF export options#3407
Enhance static report generation guide with new PDF export options#3407
Conversation
- Introduced two methods for PDF generation: a local script for batch processing and an API endpoint for on-demand requests. - Updated documentation to reflect changes in the PDF export process, including detailed implementation steps and usage scenarios. - Improved clarity on the differences between local and API-based PDF generation approaches, ensuring users can choose the best method for their needs.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Summary by CodeRabbit
WalkthroughAdds a new PDF export capability with two approaches: a local script that generates PDFs from pre-aggregated JSON and a new API endpoint that returns PDF binaries. Introduces Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client
participant API as SalesReportAPI
participant PDFGen as PDFGenerator
participant Store as JSONStore
Client->>API: GET /reports?salesReportId=123
API->>Store: fetch pre-aggregated JSON (report 123)
Store-->>API: JSON payload
API->>PDFGen: render PDF from JSON
PDFGen-->>API: binary PDF
API-->>Client: 200 application/pdf (binary)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (2)apps/framework-docs-v2/content/**/*.mdx📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Files:
apps/framework-docs-v2/content/guides/**/*.mdx📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Files:
🧠 Learnings (16)📚 Learning: 2026-01-15T19:41:53.563ZApplied to files:
📚 Learning: 2026-01-28T14:50:00.978ZApplied to files:
📚 Learning: 2026-01-15T19:41:53.563ZApplied to files:
📚 Learning: 2026-01-27T17:36:29.854ZApplied to files:
📚 Learning: 2026-01-28T14:55:13.411ZApplied to files:
📚 Learning: 2026-01-27T17:36:29.854ZApplied to files:
📚 Learning: 2026-01-27T17:36:29.854ZApplied to files:
📚 Learning: 2026-01-22T19:02:52.316ZApplied to files:
📚 Learning: 2026-01-22T19:02:52.316ZApplied to files:
📚 Learning: 2026-02-01T23:07:12.348ZApplied to files:
📚 Learning: 2026-01-19T22:37:05.393ZApplied to files:
📚 Learning: 2026-02-01T23:07:12.348ZApplied to files:
📚 Learning: 2026-02-01T23:07:12.348ZApplied to files:
📚 Learning: 2026-01-27T17:36:29.854ZApplied to files:
📚 Learning: 2026-01-27T17:36:29.854ZApplied to files:
📚 Learning: 2026-01-15T19:41:53.563ZApplied to files:
🪛 LanguageToolapps/framework-docs-v2/content/guides/static-report-generation.mdx[style] ~304-~304: ‘End result’ might be wordy. Consider a shorter alternative. (EN_WORDINESS_PREMIUM_END_RESULT) ⏰ 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). (2)
🔇 Additional comments (3)
✏️ Tip: You can disable this entire section by setting 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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/static-report-generation.mdx`:
- Around line 1558-1569: The handler currently checks for presence of startDate
and endDate but not format; add YYYY-MM-DD validation using a regex (e.g.,
/^\d{4}-\d{2}-\d{2}$/) and validate startDate and endDate before proceeding; if
either fails the regex, respond with res.writeHead(400, { "Content-Type":
"application/json" }) and res.end(JSON.stringify({ error: "startDate and endDate
must be in YYYY-MM-DD format" })); ensure you reference the existing variables
startDate and endDate and perform this check in the handler right after the
presence check to prevent downstream ClickHouse errors.
- Around line 1029-1031: Approach A uses level-3 headings (###) while Approach B
uses level-4 (####); update the Approach A step headings "Step 1: Install
pdfmake", "Step 2: …", "Step 3: …", and "Step 4: …" to use level-4 headings
(i.e., change the leading ### to ####) so the heading hierarchy matches Approach
B; locate these headings by the exact texts within the "Approach A: Local
script" section and apply the same change for the three additional steps
referenced.
- Around line 1637-1638: The curl examples use a path that doesn't match the
WebApp mounting: update examples to call the configured mountPath (/reports)
rather than /reports/sales-report-pdf, or change the routing in the handler;
specifically, adjust any examples referencing salesReportPdfApi or the WebApp
created via new WebApp("salesReportPdf", handler, { mountPath: "/reports" }) to
use http://localhost:4000/reports?startDate=... (and similarly for endDate) OR
implement explicit sub-route parsing inside the handler to accept the
/sales-report-pdf segment if that path was intended.
📜 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.
📒 Files selected for processing (1)
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🧰 Additional context used
📓 Path-based instructions (2)
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🧠 Learnings (4)
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/apis/*.ts : Always separate routing from business logic in APIs. Route files should be thin (~10 lines per endpoint) and contain only HTTP handling, while service files contain all business logic.
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/ingest/models.ts : Data models in ingest/models.ts should define interfaces using the Model naming convention, and create corresponding IngestPipeline instances with table, stream, and ingestApi options enabled
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🪛 LanguageTool
apps/framework-docs-v2/content/guides/static-report-generation.mdx
[style] ~303-~303: ‘End result’ might be wordy. Consider a shorter alternative.
Context: ... --> F --> G E --> H --> I ``` ### End result 1. File loader script for CSV/JSON ing...
(EN_WORDINESS_PREMIUM_END_RESULT)
🔇 Additional comments (6)
apps/framework-docs-v2/content/guides/static-report-generation.mdx (6)
1365-1384: LGTM on pdfmake setup and font configuration.Standard PDF fonts with Helvetica family are portable and don't require external font files. The
require()usage for pdfmake is correctly noted as necessary due to missing ESM exports.
1577-1607: Query building duplicates logic from salesReport.ts.Both this handler and
salesReport.ts(lines 929-959) have nearly identical conditional query construction. This is acceptable for documentation clarity, but consider extracting to a shared helper in production code.
1680-1694: Clear guidance on when to use each approach.The comparison table and explanation effectively communicate the trade-offs between local script and API endpoint approaches.
1826-1841: "How Moose helps" section adds valuable context.Maps ClickHouse best practices to Moose abstractions well. Links back to the earlier "Why Moose for static reports?" section appropriately.
2002-2006: Reference table updates are consistent.File descriptions correctly distinguish JSON API vs PDF API (binary response) and clarify the local script purpose.
1400-1404: pdfmake 0.3getBuffer()returnsPromise<Buffer>— code usage is correct.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
apps/framework-docs-v2/content/guides/static-report-generation.mdx
Outdated
Show resolved
Hide resolved
- Changed section headings from "Step" to "Step" for improved hierarchy. - Added validation for date format in the PDF generation process to ensure correct input. - Updated curl command examples to reflect the correct API endpoint for generating reports. - Enhanced overall documentation for better user guidance and understanding.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/static-report-generation.mdx`:
- Around line 1585-1616: The duplicated SQL in the two branches for building
query should be consolidated: create a base sql template for the
SELECT/GROUP/ORDER using the same fields (saleDate, region, productCategory,
summed columns) and the FROM ${targetTable} plus the saleDate BETWEEN
${startDate} AND ${endDate} predicate, then conditionally append an AND region =
${region} fragment only when region is provided and assign the combined sql to
query; reference the existing variables/query name (query), the sql template
literal helper (sql), and the parameters (${targetTable}, ${startDate},
${endDate}, ${region}) when implementing the conditional fragment—verify Moose's
sql template supports concatenation/conditional fragments before applying.
- Around line 1402-1406: The function generatePdfBuffer currently types its
return as Promise<Buffer> but pdfmake's getBuffer() returns Uint8Array in
browsers (Node Buffer extends Uint8Array), so change the signature of
generatePdfBuffer to return Promise<Uint8Array> and update any callers to
convert to Buffer only when running in Node (e.g., use Buffer.from(u8) where fs
or Node-only APIs require a Buffer); update any related types or docs
referencing generatePdfBuffer to reflect Promise<Uint8Array>.
📜 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.
📒 Files selected for processing (1)
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🧰 Additional context used
📓 Path-based instructions (2)
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🧠 Learnings (6)
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/apis/*.ts : API route files should follow a consistent error handling pattern: call service function inside try-catch, return result with res.json(), and respond with 500 status and error message on failure
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/apis/*.ts : Always separate routing from business logic in APIs. Route files should be thin (~10 lines per endpoint) and contain only HTTP handling, while service files contain all business logic.
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2025-12-16T23:09:00.546Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T23:09:00.546Z
Learning: When changing MooseStack functionality, ALWAYS run end-to-end tests located in `apps/framework-cli-e2e`
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/ingest/models.ts : Data models in ingest/models.ts should define interfaces using the Model naming convention, and create corresponding IngestPipeline instances with table, stream, and ingestApi options enabled
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🪛 LanguageTool
apps/framework-docs-v2/content/guides/static-report-generation.mdx
[style] ~304-~304: ‘End result’ might be wordy. Consider a shorter alternative.
Context: ... --> F --> G E --> H --> I ``` ### End result 1. File loader script for CSV/JSON ing...
(EN_WORDINESS_PREMIUM_END_RESULT)
🔇 Additional comments (8)
apps/framework-docs-v2/content/guides/static-report-generation.mdx (8)
291-302: LGTM!Architecture diagram correctly shows both PDF generation paths: local script via consumption API and direct binary response via PDF API.
1023-1043: LGTM!Heading hierarchy is now consistent—both approaches use
###for the approach title and####for steps within.
1565-1578: LGTM!Date format validation added per previous review feedback. Proper 400 responses with descriptive error messages.
1674-1681: LGTM!Curl examples correctly use
/reportsmatching themountPathconfiguration at line 1647.
1637-1641: LGTM!Error handling logs details server-side while returning sanitized 500 response to client. Consistent with API route error handling patterns.
1835-1850: LGTM!Clear mapping of ClickHouse best practices to Moose abstractions. Reinforces the developer-first value proposition.
1875-1886: LGTM!Component descriptions accurately distinguish between JSON API and PDF export options.
2006-2015: LGTM!Project structure table correctly lists both API files with clear descriptions distinguishing JSON vs binary PDF responses.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/static-report-generation.mdx`:
- Around line 1566-1578: Add a date-order validation after the existing
YYYY-MM-DD format checks to ensure startDate is not after endDate: parse
startDate and endDate into comparable Date objects (or use ISO string comparison
since format is YYYY-MM-DD) and if startDate > endDate, respond with a 400 and a
clear JSON error like "startDate must be on or before endDate"; update the
handler where startDate and endDate are checked (the same block that uses
dateRegex) so the request returns a validation error instead of proceeding and
producing empty results.
📜 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.
📒 Files selected for processing (1)
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🧰 Additional context used
📓 Path-based instructions (2)
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🧠 Learnings (6)
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/apis/*.ts : API route files should follow a consistent error handling pattern: call service function inside try-catch, return result with res.json(), and respond with 500 status and error message on failure
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/apis/*.ts : Always separate routing from business logic in APIs. Route files should be thin (~10 lines per endpoint) and contain only HTTP handling, while service files contain all business logic.
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2025-12-16T23:09:00.546Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T23:09:00.546Z
Learning: When changing MooseStack functionality, ALWAYS run end-to-end tests located in `apps/framework-cli-e2e`
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/ingest/models.ts : Data models in ingest/models.ts should define interfaces using the Model naming convention, and create corresponding IngestPipeline instances with table, stream, and ingestApi options enabled
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🪛 LanguageTool
apps/framework-docs-v2/content/guides/static-report-generation.mdx
[style] ~304-~304: ‘End result’ might be wordy. Consider a shorter alternative.
Context: ... --> F --> G E --> H --> I ``` ### End result 1. File loader script for CSV/JSON ing...
(EN_WORDINESS_PREMIUM_END_RESULT)
🔇 Additional comments (5)
apps/framework-docs-v2/content/guides/static-report-generation.mdx (5)
279-309: LGTM!Architecture diagram and end result section accurately reflect the dual PDF generation paths (local script and API endpoint).
1021-1032: LGTM!Clear structure introducing both approaches. Heading hierarchy is consistent (### for approach headers, #### for steps).
1580-1642: LGTM!Solid error handling: queries ClickHouse directly via
getMooseUtils(), returns 404 for empty results, 500 with logged error on failure. Binary PDF response headers are correct. Based on learnings, the try-catch pattern with appropriate status codes follows API best practices.
1669-1703: LGTM!Curl examples correctly use
/reportsmatching themountPath. Response codes are documented. The "when to use each approach" table provides clear guidance for choosing between local script and API endpoint.
1988-2015: LGTM!File tree and reference table correctly include
salesReportPdf.tswith accurate descriptions distinguishing JSON vs binary PDF endpoints.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
- Implemented a check to ensure that the start date is before or equal to the end date, returning a 400 error if the validation fails. - This enhancement improves the robustness of the report generation process by preventing invalid date inputs.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/static-report-generation.mdx`:
- Line 1366: Two new TypeScript code blocks in the docs are missing the `@test`
directive so they won't be validated by the snippet tests; update each
```typescript code fence (the new TypeScript snippets added) to include the
`@test` tag (i.e., change ```typescript to ```typescript `@test`) so the docs
snippet tests will run against those blocks.
📜 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.
📒 Files selected for processing (1)
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🧰 Additional context used
📓 Path-based instructions (2)
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🧠 Learnings (12)
📚 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-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/apis/*.ts : API route files should follow a consistent error handling pattern: call service function inside try-catch, return result with res.json(), and respond with 500 status and error message on failure
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-28T14:50:00.978Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:00.978Z
Learning: When reviewing WebApp implementations that run in a Node.js backend, prefer Node.js-specific types (e.g., Buffer) and avoid browser-focused cross-platform compatibility considerations. This guideline applies to MDX documentation and code examples across the repository where backend/runtime code is discussed; ensure reviewers distinguish server-side context from frontend/browser constraints and validate type usage accordingly.
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/apis/*.ts : Always separate routing from business logic in APIs. Route files should be thin (~10 lines per endpoint) and contain only HTTP handling, while service files contain all business logic.
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/**/*.ts : Query example functions must use `eventsModel.toSql()` to generate SQL, ensuring consistent query construction through the defined model
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-28T14:55:13.411Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1585-1616
Timestamp: 2026-01-28T14:55:13.411Z
Learning: In documentation and tutorial files under apps/framework-docs-v2/content/guides/, prefer explicit, self-contained code examples that may duplicate small snippets for clarity over abstracting with DRY helpers. Ensure examples are easy to understand in isolation, even if it means a bit of repetition, to aid learning and reduce cognitive load for readers.
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: Applies to examples/nextjs-moose/**/*.ts : Use type inference helpers (`$inferRequest`, `$inferDimensions`, `$inferMetrics`) from query model definitions to ensure type-safe query parameter construction
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: Applies to examples/nextjs-moose/components/report-builder/**/*.ts : Report builder components must use `prepareModel()` to transform backend model definitions for frontend consumption, configuring UI input types and options
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2025-12-16T23:09:00.546Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-16T23:09:00.546Z
Learning: When changing MooseStack functionality, ALWAYS run end-to-end tests located in `apps/framework-cli-e2e`
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-27T17:36:29.825Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.825Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/ingest/models.ts : Data models in ingest/models.ts should define interfaces using the Model naming convention, and create corresponding IngestPipeline instances with table, stream, and ingestApi options enabled
Applied to files:
apps/framework-docs-v2/content/guides/static-report-generation.mdx
🪛 LanguageTool
apps/framework-docs-v2/content/guides/static-report-generation.mdx
[style] ~304-~304: ‘End result’ might be wordy. Consider a shorter alternative.
Context: ... --> F --> G E --> H --> I ``` ### End result 1. File loader script for CSV/JSON ing...
(EN_WORDINESS_PREMIUM_END_RESULT)
🔇 Additional comments (3)
apps/framework-docs-v2/content/guides/static-report-generation.mdx (3)
291-310: Diagram + deliverables update is clear.The architecture and end-result list now reflect both PDF paths cleanly.
1023-1032: Two‑approach framing reads well.The intro and step headings make the local-vs-API split easy to scan.
Also applies to: 1043-1043, 1313-1313, 1339-1339, 1350-1364
1661-1667: Examples + wrap‑up updates are cohesive.The callout, curl examples, comparison table, and wrap‑up/file‑tree updates align well with the new PDF API flow.
Also applies to: 1676-1710, 1842-1857, 1885-1891, 1997-1997, 2018-2021
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
…larifications - Added a warning callout to inform users to stop other Moose projects before starting a new one to avoid port conflicts. - Updated service health check response description for clarity. - Revised the expected response for the ingest command to indicate a simplified success message. - Expanded troubleshooting section to include port 9000 and added guidance on TypeScript error persistence after code fixes.
Note
Low Risk
Low risk documentation-only change that adds a new binary PDF download approach and updates several expected command outputs; main risk is reader confusion if the described responses/mount paths don’t match current runtime behavior.
Overview
Adds a second PDF export path to the static report generation guide: alongside the existing local
pdfmakescript, it now documents aWebApp-based/reportsendpoint that queries ClickHouse and returns a binary PDF response (including parameter validation and curl download examples).Updates the tutorial narrative and diagrams to reflect the two approaches, clarifies reserved mount path constraints, and adjusts several setup/troubleshooting expectations (port conflicts including
9000,/healthresponse shape, and ingest endpoint returningSUCCESS).Written by Cursor Bugbot for commit 718536c. This will update automatically on new commits. Configure here.