docs: quality pass across the integration guides#2068
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
🚧 Files skipped from review as they are similar to previous changes (10)
📝 WalkthroughWalkthroughReworked integration documentation across databases, event streams, HTTP clients, LLMs, logging utilities, metrics, and web frameworks. The guides now use consistent sections for captured data, prerequisites, installation, usage, verification, troubleshooting, advanced configuration, and references. Examples and instrumentation ordering were updated, while landing pages and specialized guidance for collectors, worker hooks, request filtering, SQL comments, and telemetry proxying were reorganized. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 14
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/integrations/databases/asyncpg.md (1)
49-65: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winUse
localhostin the local PostgreSQL example.0.0.0.0is a bind address, not a client destination; update both the URL andasyncpg.connect()call tolocalhostor127.0.0.1so the copy-paste example connects correctly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/databases/asyncpg.md` around lines 49 - 65, Update the local PostgreSQL example to use localhost as the client destination: replace 0.0.0.0 with localhost in both the introductory database URL and the asyncpg.connect() call, leaving the remaining connection parameters unchanged.docs/integrations/pytest.md (1)
86-91: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winMake the
pyproject.tomlexample compatible with the supported pytest version.pytest 8.3.4still uses[tool.pytest.ini_options];[tool.pytest]only works with pytest 9+, so this example will be ignored by users on the current minimum version. Switch the example or state a pytest 9 requirement.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/pytest.md` around lines 86 - 91, Update the pyproject.toml configuration example in the pytest documentation to use the supported pytest 8.3.4 table name, [tool.pytest.ini_options], so the logfire setting is recognized. Do not introduce a pytest 9 requirement unless the documentation explicitly intends to raise the minimum supported version.
🟡 Minor comments (30)
docs/integrations/aws-lambda.md-13-17 (1)
13-17: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winState that captured telemetry is transmitted to Logfire.
This section lists invocation, error, and nested-span data without explaining that the data leaves the Lambda environment and is sent to the configured Logfire project. Add a concise data-handling note, with retention or pricing guidance if applicable.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/aws-lambda.md` around lines 13 - 17, Update the “What you’ll capture” section to add a concise note that captured telemetry is transmitted from the Lambda environment to the configured Logfire project. Include retention or pricing guidance only if established documentation already provides it.Source: Coding guidelines
docs/integrations/databases/mysql.md-50-50 (1)
50-50: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUse
localhostin the connection URL.0.0.0.0is a bind address, not a client destination, so readers can copy a URL that won’t connect. The code example already useslocalhost.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/databases/mysql.md` at line 50, Update the MySQL connection URL in the documentation text to use localhost instead of 0.0.0.0, matching the existing code example and ensuring readers receive a valid client destination.docs/integrations/databases/redis.md-41-41 (1)
41-41: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winSecurity Misconfiguration (CWE-306): Missing Authentication for Critical Function
Reachability: External
Bind the Redis example to loopback
-p 6379:6379exposes the container on all host interfaces; use-p 127.0.0.1:6379:6379here, and add auth/networking guidance if remote access is intended.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/databases/redis.md` at line 41, Update the Redis Docker command to bind port 6379 to loopback using 127.0.0.1:6379:6379 instead of exposing it on all host interfaces; do not add remote-access guidance unless remote access is explicitly intended.docs/integrations/databases/pymongo.md-45-45 (1)
45-45: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winSecurity Misconfiguration (CWE-306): Missing Authentication for Critical Function
Reachability: External
Bind MongoDB to loopback
-p 27017:27017publishes the container on every host interface, so anyone who can reach the machine can connect to the unauthenticated example database. Use-p 127.0.0.1:27017:27017for a local-only demo; if remote access is intended, document authentication and network restrictions.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/databases/pymongo.md` at line 45, Update the MongoDB docker run command to bind port 27017 specifically to 127.0.0.1, keeping the local-only unauthenticated demo inaccessible from other host interfaces.docs/integrations/databases/psycopg.md-55-65 (1)
55-65: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUse
localhostfor the PostgreSQL example.0.0.0.0is a bind address, not a client destination, so the URL andpsycopg.connect(...)should point atlocalhostor127.0.0.1. The same address appears again in the advanced example below.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/databases/psycopg.md` around lines 55 - 65, Update the PostgreSQL connection examples to use localhost instead of 0.0.0.0 in both the displayed database URL and psycopg.connect call, including the repeated address in the advanced example below.docs/integrations/web-frameworks/wsgi.md-8-16 (1)
8-16: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winSpell out WSGI.
Define it as “Web Server Gateway Interface (WSGI)” in the introduction instead of only describing it as the standard interface.
As per coding guidelines, public documentation must spell out field-specific acronyms at first use and explain specialized terms in plain language.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/web-frameworks/wsgi.md` around lines 8 - 16, Update the introductory WSGI definition to spell out “Web Server Gateway Interface (WSGI)” at first use, while preserving the existing explanation and framework integration guidance.Source: Coding guidelines
docs/integrations/web-frameworks/starlette.md-97-101 (1)
97-101: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winExpand ASGI at first use.
Use “Asynchronous Server Gateway Interface (ASGI)” before the acronym so readers can understand this specialized term.
As per coding guidelines, public documentation must spell out field-specific acronyms at first use and explain specialized terms in plain language.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/web-frameworks/starlette.md` around lines 97 - 101, Update the first use of “ASGI” in the “Why not the OpenTelemetry ASGI middleware?” section to spell out “Asynchronous Server Gateway Interface (ASGI),” while preserving the existing explanation and link.Source: Coding guidelines
docs/integrations/llms/anthropic.md-13-18 (1)
13-18: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winSensitive Data Exposure (CWE-200): Exposure of Sensitive Information to an Unauthorized Actor
Reachability: External
Disclose that captured content is sent to Logfire.
The page advertises full conversations and tool calls but does not plainly explain that this content is transmitted to Logfire or advise users about sensitive data. Add a short disclosure near “Before you start.”
As per coding guidelines, public documentation must plainly state consequences such as data transmission and redaction.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/anthropic.md` around lines 13 - 18, Add a concise disclosure near the “Before you start” section explaining that captured conversations, responses, streaming data, and tool calls are transmitted to Logfire, and advise users to redact sensitive information before enabling tracing.Source: Coding guidelines
docs/integrations/llms/openai.md-16-21 (1)
16-21: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winSensitive Data Exposure (CWE-200): Exposure of Sensitive Information to an Unauthorized Actor
Reachability: External
Disclose that OpenAI content is sent to Logfire.
The page advertises full conversations and tool calls but does not plainly explain that this content is transmitted to Logfire or advise users about sensitive data. Add a short disclosure near “Before you start.”
As per coding guidelines, public documentation must plainly state consequences such as data transmission and redaction.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/openai.md` around lines 16 - 21, Add a concise disclosure near the “Before you start” section explaining that OpenAI conversation content and tool-call data are transmitted to Logfire, and advise users to review or redact sensitive information before enabling the integration.Source: Coding guidelines
docs/integrations/llms/google-genai.md-80-80 (1)
80-80: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winResolve the verification TODO before publishing.
The Live-view span name and expanded conversation screenshot remain unverified. Complete the check or remove the placeholder.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/google-genai.md` at line 80, Resolve the TODO in the Google GenAI integration documentation by verifying the Live-view span name for generate_content and adding the expanded conversation screenshot, or remove the placeholder if the verification cannot be completed.docs/integrations/llms/pydanticai.md-10-16 (1)
10-16: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winSensitive Data Exposure (CWE-200): Exposure of Sensitive Information to an Unauthorized Actor
Reachability: External
Disclose that agent content is sent to Logfire.
The page says it captures full conversations and tool arguments/results but does not plainly explain that this content is transmitted to Logfire or advise users about sensitive data. Add a concise disclosure near “Before you start.”
As per coding guidelines, public documentation must plainly state consequences such as data transmission and redaction.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/pydanticai.md` around lines 10 - 16, Add a concise disclosure near “Before you start” stating that agent conversations, tool arguments/results, and related content are transmitted to Logfire, and advise users to redact sensitive data before tracing.Source: Coding guidelines
docs/integrations/llms/dspy.md-14-19 (1)
14-19: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winSensitive Data Exposure (CWE-200): Exposure of Sensitive Information to an Unauthorized Actor
Reachability: External
Disclose that prompts and responses are sent to Logfire.
This page explicitly captures generated prompts and model responses but does not explain that this content is transmitted to Logfire or how users should handle sensitive data. Add a concise disclosure near “Before you start.”
As per coding guidelines, public documentation must plainly state consequences such as data transmission and redaction.
Also applies to: 21-29
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/dspy.md` around lines 14 - 19, Add a concise disclosure near “Before you start” in the DSPy integration documentation stating that generated prompts and model responses are transmitted to Logfire, and advise users to redact or avoid sensitive data before tracing. Keep the existing capture description unchanged.Source: Coding guidelines
docs/integrations/llms/pydanticai.md-73-73 (1)
73-73: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winFix the broken
KnownModelNamereference.The link target
pydantic_ai.models.KnownModelNameis undefined, so this model-list link will render as broken. Define the reference label or replace it with a valid direct URL.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/pydanticai.md` at line 73, Fix the model-list link in the Pydantic AI documentation by replacing the undefined pydantic_ai.models.KnownModelName target with a valid direct URL or a properly defined reference label, while preserving the existing link text and sentence.Source: Linters/SAST tools
docs/integrations/llms/claude-agent-sdk.md-13-23 (1)
13-23: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winSensitive Data Exposure (CWE-200): Exposure of Sensitive Information to an Unauthorized Actor
Reachability: External
Disclose that agent data is sent to Logfire.
The page says it captures conversations and tool arguments/results, but only explains provider cost. Add a clear note that captured content is transmitted to Logfire and may contain sensitive data.
As per coding guidelines, public documentation must plainly state consequences such as data transmission and redaction.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/claude-agent-sdk.md` around lines 13 - 23, Add a clear note in the “What you'll capture” or “Before you start” section stating that captured conversations, tool arguments, results, and errors are transmitted to Logfire and may contain sensitive data; advise users to redact sensitive content as appropriate.Source: Coding guidelines
docs/integrations/llms/openai.md-88-88 (1)
88-88: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winResolve the verification TODO before publishing.
The Live-view span name and expanded conversation screenshot remain unverified. Complete the check or remove the placeholder.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/openai.md` at line 88, Resolve the TODO in the OpenAI integration documentation by verifying the Live-view span name for chat completion calls and adding the screenshot of the expanded conversation view, or remove the placeholder if the verification cannot be included. Do not leave the unresolved TODO before publishing.docs/integrations/llms/anthropic.md-88-88 (1)
88-88: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winResolve the verification TODO before publishing.
The new verification section still leaves the span name and expanded-view screenshot unconfirmed. Complete the check or remove the placeholder and keep the instructions generic.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/anthropic.md` at line 88, Resolve the verification TODO in the Live-view verification section before publishing: confirm the span name for messages.create and add the expanded conversation-view screenshot, or remove the placeholder and keep the verification instructions generic.docs/integrations/llms/pydanticai.md-85-85 (1)
85-85: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winResolve the verification TODO before publishing.
The example trace screenshot remains explicitly unverified. Complete the check or remove the placeholder before presenting this as finished documentation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/pydanticai.md` at line 85, Resolve the verification TODO in the Pydantic AI documentation by completing the Live view trace verification and adding the resulting screenshot, or remove the placeholder if no screenshot is needed. Do not leave the explicit app-verify TODO in the published documentation.docs/integrations/llms/dspy.md-87-87 (1)
87-87: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winResolve the verification TODO before publishing.
The Live-view span names and nested-trace screenshot remain unverified. Complete the check or remove the placeholder.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/dspy.md` at line 87, Resolve the app-verify TODO in the dspy.Predict documentation by confirming the Live-view span names and adding the nested-trace screenshot, or remove the placeholder if verification cannot be completed. Do not leave the TODO unresolved before publishing.docs/integrations/llms/openai.md-226-227 (1)
226-227: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winFix the undefined
instrument_openai_agents()reference.The agents API reference label is not defined, so these links render as broken references. Define the reference label or replace it with a valid direct/API reference link.
Also applies to: 289-292
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/openai.md` around lines 226 - 227, Fix the undefined logfire.Logfire.instrument_openai_agents reference in the OpenAI integrations documentation, including the repeated occurrence near the additional affected section. Define a matching reference label with the correct API documentation target, or replace both references with valid direct links while preserving the existing link text.Source: Linters/SAST tools
docs/integrations/llms/claude-agent-sdk.md-107-107 (1)
107-107: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winResolve the verification TODO before publishing.
The verification screenshot is still explicitly unconfirmed. Complete the check or remove the placeholder before presenting this as a finished verification workflow.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/claude-agent-sdk.md` at line 107, Resolve the verification TODO in the Claude Agent SDK documentation by completing the Live view trace check and adding the resulting screenshot, or remove the placeholder if verification is complete without it. Do not leave the app-verify TODO in the published workflow.docs/integrations/llms/llamaindex.md-13-14 (1)
13-14: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winFix the malformed OpenLLMetry link syntax.
[OpenLLMetry]:is reference-definition syntax in the middle of a sentence. Use[OpenLLMetry], specifically ...; keep the actual reference definition at the bottom of the page.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/llamaindex.md` around lines 13 - 14, Update the LlamaIndex recommendation sentence so “OpenLLMetry” is an inline link followed by “specifically,” rather than using reference-definition syntax mid-sentence; preserve the existing OpenLLMetry reference definition at the bottom of the page.docs/integrations/llms/llamaindex.md-22-27 (1)
22-27: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winInformation Disclosure (CWE-200): Exposure of Sensitive Information to an Unauthorized Actor
Reachability: External
Add explicit data-transfer and cost disclosures.
The page lists retrieval context and model calls as captured, but does not plainly say that this content is sent to Logfire or that running the OpenAI example may incur provider charges.
As per coding guidelines, public documentation must plainly state consequences such as data transmission and cost.
Also applies to: 43-46
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/llamaindex.md` around lines 22 - 27, Update the documentation around the “Before you start” section and the captured retrieval/model-call content to explicitly state that this data is transmitted to Logfire and that running the OpenAI example may incur provider charges. Keep the existing setup guidance intact while making both disclosures clear and prominent.Source: Coding guidelines
docs/integrations/llms/mcp.md-18-22 (1)
18-22: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDocument
OPENAI_API_KEYhere. The client example usesopenai:gpt-4o, but this section only says “your own API key”; spell out theOPENAI_API_KEYenvironment variable and where to get it.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/mcp.md` around lines 18 - 22, Update the “Before you start” section in docs/integrations/llms/mcp.md to explicitly require the OPENAI_API_KEY environment variable for the openai:gpt-4o example, and state where users can obtain that key. Keep the existing Logfire write-token and cost information unchanged.Source: Coding guidelines
docs/integrations/llms/mirascope.md-19-23 (1)
19-23: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDocument the Anthropic API key the example needs. The prerequisites only mention “your own API key”; call out
ANTHROPIC_API_KEYhere (or link to the provider setup docs) so readers can run the sample without guessing.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/mirascope.md` around lines 19 - 23, Update the “Before you start” section in the Mirascope integration documentation to explicitly state that the example requires the ANTHROPIC_API_KEY environment variable, optionally linking to Anthropic’s provider setup documentation, while preserving the existing Logfire write-token prerequisite.Source: Coding guidelines
docs/integrations/llms/magentic.md-20-24 (1)
20-24: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winMake the provider key requirement explicit.
This page says Magentic uses “your own API key,” but it should name the provider-specific env var(s) and where to get them, or link directly to the OpenAI/Anthropic setup docs, so readers can run the example without guessing.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/magentic.md` around lines 20 - 24, Update the “Before you start” section in the Magentic documentation to explicitly identify the provider API key environment variable(s) required by the example and explain where to obtain them, or link to the relevant OpenAI/Anthropic setup documentation. Replace the vague “your own API key” wording while preserving the existing Logfire write-token instructions.Source: Coding guidelines
docs/integrations/index.md-2-3 (1)
2-3: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winFix the malformed frontmatter description.
“most a single” is missing a verb. Use “most integrations use a single
logfire.instrument_<package>()call” or equivalent.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/index.md` around lines 2 - 3, Update the frontmatter description in the integrations documentation so the phrase “most a single” includes the missing verb, stating that most integrations use a single logfire.instrument_<package>() call while preserving the rest of the description.docs/integrations/system-metrics.md-8-17 (1)
8-17: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winSpell out CPU at first use.
Use “central processing unit (CPU)” when first introducing the term, then use
CPUafterward. As per coding guidelines, public documentation must spell out field-specific acronyms at first use. Based on learnings, only the explicitly approved common acronyms are exempt from expansion.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/system-metrics.md` around lines 8 - 17, Update the first CPU reference in the introductory text to “central processing unit (CPU),” preserving subsequent CPU uses such as “CPU usage” unchanged.Sources: Coding guidelines, Learnings
docs/integrations/logging.md-8-12 (1)
8-12: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winDefine the
[logging]reference link.The introduction uses
[logging][], but no[logging]definition is present in the supplied file. This triggers MD052 and leaves the rendered link unresolved. Add a reference definition for Python’s logging documentation.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/logging.md` around lines 8 - 12, Add a `[logging]` reference definition in the documentation file, pointing to Python’s official logging documentation, so the existing `[logging][]` reference resolves correctly without changing the surrounding introduction.Source: Linters/SAST tools
docs/integrations/pytest.md-93-101 (1)
93-101: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winExpand
CIat first use.Change the heading or first sentence to “continuous integration (CI)”; use
CIthereafter.As per coding guidelines, public documentation must spell out field-specific acronyms at first use.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/pytest.md` around lines 93 - 101, Update the “Auto-enable in CI” documentation heading or its first sentence to spell out “continuous integration (CI)” at first use, then retain “CI” for subsequent references in the section.Sources: Coding guidelines, Learnings
docs/integrations/pytest.md-194-194 (1)
194-194: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winCall these logs, not spans.
logfire_pytest.info()emits log records; describe them as log records nested under the test span.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/pytest.md` at line 194, Update the “Example: logging during tests” documentation to describe logfire_pytest.info() output as log records nested under the test span, not as spans. Ensure the surrounding wording consistently uses “log records” for these emitted entries.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/integrations/databases/bigquery.md`:
- Around line 31-36: Add google-cloud-bigquery to the Installation step in the
BigQuery documentation alongside the existing install_logfire() instruction, so
environments installing the documented dependencies can import
google.cloud.bigquery successfully.
In `@docs/integrations/databases/psycopg.md`:
- Around line 57-65: Update the Psycopg example around the `import psycopg` and
`psycopg.connect` symbols to explicitly label it as Psycopg 3-only, and change
the connection host from `0.0.0.0` to `localhost` or `127.0.0.1`. Keep the
existing Psycopg 3 instrumentation flow unchanged.
In `@docs/integrations/event-streams/airflow.md`:
- Around line 37-41: Update the Installation section of the Airflow integration
guide to state that OpenTelemetry support requires the apache-airflow[otel]
extra, or explicitly say the guide assumes that extra is already installed. Keep
the existing guidance about not needing the separate logfire package.
In `@docs/integrations/event-streams/celery.md`:
- Around line 75-80: Move the `add.delay(42, 50)` producer call out of
`tasks.py` module scope so importing the Celery worker module does not enqueue
tasks automatically. Place the trigger in a separate producer script or behind
an explicit command, while preserving the existing worker task definition and
usage instructions.
- Around line 35-37: Update the Celery tracing setup documentation to call
logfire.configure() and logfire.instrument_celery() from Celery’s
worker_process_init signal instead of worker_init, ensuring initialization
occurs separately after each worker process starts. Preserve the instruction to
invoke both calls once per worker process.
In `@docs/integrations/http-clients/aiohttp.md`:
- Line 208: Update the documentation around the AIOHTTP header hooks to state
that built-in header capture occurs before run_hook, so hooks cannot filter or
modify headers already captured by capture_headers=True. Clarify that users may
instead capture a filtered copy themselves, but must not rely on hooks to
sanitize built-in capture.
In `@docs/integrations/http-clients/httpx.md`:
- Line 207: Update the HTTPX hooks documentation to state that built-in header
capture occurs before the user hook runs, so hooks cannot redact headers
recorded by capture_headers=True. Clarify that hooks may capture a filtered copy
themselves, but cannot sanitize headers already captured by the built-in
mechanism.
In `@docs/integrations/llms/langchain.md`:
- Around line 24-29: Update the “Before you start” section for the create_agent
example to document the required OPENAI_API_KEY prerequisite and explain where
to obtain it, alongside the existing Logfire write-token setup; alternatively,
change the example to use a model that does not require provider credentials.
In `@docs/integrations/llms/litellm.md`:
- Around line 8-20: Add an explicit disclosure near the “What you'll capture”
list stating that captured model conversations and responses are transmitted to
Logfire. Include the applicable retention or redaction guidance if an existing
documented policy is available, without changing the described capture behavior.
In `@docs/integrations/llms/magentic.md`:
- Around line 8-18: Update the “What you’ll capture” section in the Magentic
integration documentation to explicitly disclose that captured prompts,
messages, tool/function calls, and related model data are sent to Logfire. Keep
the existing capture list and clarify the data-transfer behavior without
changing instrumentation instructions.
In `@docs/integrations/llms/mcp.md`:
- Around line 8-16: Update the MCP guide near the “What you'll capture” section
to explicitly state that tool arguments and server results are transmitted to
Logfire for tracing. Add a clear privacy/data-transmission note while preserving
the existing description of captured spans and distributed traces.
In `@docs/integrations/llms/mirascope.md`:
- Around line 8-17: Update the introductory capture description in the Mirascope
documentation to explicitly state that captured prompts, conversations, tool
calls, and token usage are sent to Logfire. Keep the existing capture details
intact and make the transmission disclosure clear to readers.
In `@docs/integrations/stripe.md`:
- Around line 112-116: Update the Stripe logging example near “Add Stripe's log
messages” to scope its handler configuration to logging.getLogger('stripe')
instead of configuring the root logger with basicConfig(). Ensure the example
captures Stripe logs without enabling unrelated propagated application INFO
logs, or explicitly document the broader global scope if root logging must
remain.
In `@docs/integrations/web-frameworks/gunicorn.md`:
- Around line 8-20: Update the generic Gunicorn example so it explicitly
instruments myapp:app in addition to calling logfire.configure(), using the
project’s established instrument_* integration step. Ensure the verification
instructions and “What you’ll capture” claims match this setup, or narrow them
to applications that are already instrumented; preserve per-worker
initialization.
---
Outside diff comments:
In `@docs/integrations/databases/asyncpg.md`:
- Around line 49-65: Update the local PostgreSQL example to use localhost as the
client destination: replace 0.0.0.0 with localhost in both the introductory
database URL and the asyncpg.connect() call, leaving the remaining connection
parameters unchanged.
In `@docs/integrations/pytest.md`:
- Around line 86-91: Update the pyproject.toml configuration example in the
pytest documentation to use the supported pytest 8.3.4 table name,
[tool.pytest.ini_options], so the logfire setting is recognized. Do not
introduce a pytest 9 requirement unless the documentation explicitly intends to
raise the minimum supported version.
---
Minor comments:
In `@docs/integrations/aws-lambda.md`:
- Around line 13-17: Update the “What you’ll capture” section to add a concise
note that captured telemetry is transmitted from the Lambda environment to the
configured Logfire project. Include retention or pricing guidance only if
established documentation already provides it.
In `@docs/integrations/databases/mysql.md`:
- Line 50: Update the MySQL connection URL in the documentation text to use
localhost instead of 0.0.0.0, matching the existing code example and ensuring
readers receive a valid client destination.
In `@docs/integrations/databases/psycopg.md`:
- Around line 55-65: Update the PostgreSQL connection examples to use localhost
instead of 0.0.0.0 in both the displayed database URL and psycopg.connect call,
including the repeated address in the advanced example below.
In `@docs/integrations/databases/pymongo.md`:
- Line 45: Update the MongoDB docker run command to bind port 27017 specifically
to 127.0.0.1, keeping the local-only unauthenticated demo inaccessible from
other host interfaces.
In `@docs/integrations/databases/redis.md`:
- Line 41: Update the Redis Docker command to bind port 6379 to loopback using
127.0.0.1:6379:6379 instead of exposing it on all host interfaces; do not add
remote-access guidance unless remote access is explicitly intended.
In `@docs/integrations/index.md`:
- Around line 2-3: Update the frontmatter description in the integrations
documentation so the phrase “most a single” includes the missing verb, stating
that most integrations use a single logfire.instrument_<package>() call while
preserving the rest of the description.
In `@docs/integrations/llms/anthropic.md`:
- Around line 13-18: Add a concise disclosure near the “Before you start”
section explaining that captured conversations, responses, streaming data, and
tool calls are transmitted to Logfire, and advise users to redact sensitive
information before enabling tracing.
- Line 88: Resolve the verification TODO in the Live-view verification section
before publishing: confirm the span name for messages.create and add the
expanded conversation-view screenshot, or remove the placeholder and keep the
verification instructions generic.
In `@docs/integrations/llms/claude-agent-sdk.md`:
- Around line 13-23: Add a clear note in the “What you'll capture” or “Before
you start” section stating that captured conversations, tool arguments, results,
and errors are transmitted to Logfire and may contain sensitive data; advise
users to redact sensitive content as appropriate.
- Line 107: Resolve the verification TODO in the Claude Agent SDK documentation
by completing the Live view trace check and adding the resulting screenshot, or
remove the placeholder if verification is complete without it. Do not leave the
app-verify TODO in the published workflow.
In `@docs/integrations/llms/dspy.md`:
- Around line 14-19: Add a concise disclosure near “Before you start” in the
DSPy integration documentation stating that generated prompts and model
responses are transmitted to Logfire, and advise users to redact or avoid
sensitive data before tracing. Keep the existing capture description unchanged.
- Line 87: Resolve the app-verify TODO in the dspy.Predict documentation by
confirming the Live-view span names and adding the nested-trace screenshot, or
remove the placeholder if verification cannot be completed. Do not leave the
TODO unresolved before publishing.
In `@docs/integrations/llms/google-genai.md`:
- Line 80: Resolve the TODO in the Google GenAI integration documentation by
verifying the Live-view span name for generate_content and adding the expanded
conversation screenshot, or remove the placeholder if the verification cannot be
completed.
In `@docs/integrations/llms/llamaindex.md`:
- Around line 13-14: Update the LlamaIndex recommendation sentence so
“OpenLLMetry” is an inline link followed by “specifically,” rather than using
reference-definition syntax mid-sentence; preserve the existing OpenLLMetry
reference definition at the bottom of the page.
- Around line 22-27: Update the documentation around the “Before you start”
section and the captured retrieval/model-call content to explicitly state that
this data is transmitted to Logfire and that running the OpenAI example may
incur provider charges. Keep the existing setup guidance intact while making
both disclosures clear and prominent.
In `@docs/integrations/llms/magentic.md`:
- Around line 20-24: Update the “Before you start” section in the Magentic
documentation to explicitly identify the provider API key environment
variable(s) required by the example and explain where to obtain them, or link to
the relevant OpenAI/Anthropic setup documentation. Replace the vague “your own
API key” wording while preserving the existing Logfire write-token instructions.
In `@docs/integrations/llms/mcp.md`:
- Around line 18-22: Update the “Before you start” section in
docs/integrations/llms/mcp.md to explicitly require the OPENAI_API_KEY
environment variable for the openai:gpt-4o example, and state where users can
obtain that key. Keep the existing Logfire write-token and cost information
unchanged.
In `@docs/integrations/llms/mirascope.md`:
- Around line 19-23: Update the “Before you start” section in the Mirascope
integration documentation to explicitly state that the example requires the
ANTHROPIC_API_KEY environment variable, optionally linking to Anthropic’s
provider setup documentation, while preserving the existing Logfire write-token
prerequisite.
In `@docs/integrations/llms/openai.md`:
- Around line 16-21: Add a concise disclosure near the “Before you start”
section explaining that OpenAI conversation content and tool-call data are
transmitted to Logfire, and advise users to review or redact sensitive
information before enabling the integration.
- Line 88: Resolve the TODO in the OpenAI integration documentation by verifying
the Live-view span name for chat completion calls and adding the screenshot of
the expanded conversation view, or remove the placeholder if the verification
cannot be included. Do not leave the unresolved TODO before publishing.
- Around line 226-227: Fix the undefined
logfire.Logfire.instrument_openai_agents reference in the OpenAI integrations
documentation, including the repeated occurrence near the additional affected
section. Define a matching reference label with the correct API documentation
target, or replace both references with valid direct links while preserving the
existing link text.
In `@docs/integrations/llms/pydanticai.md`:
- Around line 10-16: Add a concise disclosure near “Before you start” stating
that agent conversations, tool arguments/results, and related content are
transmitted to Logfire, and advise users to redact sensitive data before
tracing.
- Line 73: Fix the model-list link in the Pydantic AI documentation by replacing
the undefined pydantic_ai.models.KnownModelName target with a valid direct URL
or a properly defined reference label, while preserving the existing link text
and sentence.
- Line 85: Resolve the verification TODO in the Pydantic AI documentation by
completing the Live view trace verification and adding the resulting screenshot,
or remove the placeholder if no screenshot is needed. Do not leave the explicit
app-verify TODO in the published documentation.
In `@docs/integrations/logging.md`:
- Around line 8-12: Add a `[logging]` reference definition in the documentation
file, pointing to Python’s official logging documentation, so the existing
`[logging][]` reference resolves correctly without changing the surrounding
introduction.
In `@docs/integrations/pytest.md`:
- Around line 93-101: Update the “Auto-enable in CI” documentation heading or
its first sentence to spell out “continuous integration (CI)” at first use, then
retain “CI” for subsequent references in the section.
- Line 194: Update the “Example: logging during tests” documentation to describe
logfire_pytest.info() output as log records nested under the test span, not as
spans. Ensure the surrounding wording consistently uses “log records” for these
emitted entries.
In `@docs/integrations/system-metrics.md`:
- Around line 8-17: Update the first CPU reference in the introductory text to
“central processing unit (CPU),” preserving subsequent CPU uses such as “CPU
usage” unchanged.
In `@docs/integrations/web-frameworks/starlette.md`:
- Around line 97-101: Update the first use of “ASGI” in the “Why not the
OpenTelemetry ASGI middleware?” section to spell out “Asynchronous Server
Gateway Interface (ASGI),” while preserving the existing explanation and link.
In `@docs/integrations/web-frameworks/wsgi.md`:
- Around line 8-16: Update the introductory WSGI definition to spell out “Web
Server Gateway Interface (WSGI)” at first use, while preserving the existing
explanation and framework integration guidance.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 189eba94-d92b-4fac-b18d-f15f104101ac
📒 Files selected for processing (45)
docs/integrations/aws-lambda.mddocs/integrations/databases/asyncpg.mddocs/integrations/databases/bigquery.mddocs/integrations/databases/mysql.mddocs/integrations/databases/psycopg.mddocs/integrations/databases/pymongo.mddocs/integrations/databases/redis.mddocs/integrations/databases/sqlalchemy.mddocs/integrations/databases/sqlite3.mddocs/integrations/event-streams/airflow.mddocs/integrations/event-streams/celery.mddocs/integrations/event-streams/faststream.mddocs/integrations/http-clients/aiohttp.mddocs/integrations/http-clients/httpx.mddocs/integrations/http-clients/requests.mddocs/integrations/index.mddocs/integrations/llms/anthropic.mddocs/integrations/llms/claude-agent-sdk.mddocs/integrations/llms/dspy.mddocs/integrations/llms/google-genai.mddocs/integrations/llms/langchain.mddocs/integrations/llms/litellm.mddocs/integrations/llms/llamaindex.mddocs/integrations/llms/magentic.mddocs/integrations/llms/mcp.mddocs/integrations/llms/mirascope.mddocs/integrations/llms/openai.mddocs/integrations/llms/pydanticai.mddocs/integrations/logging.mddocs/integrations/loguru.mddocs/integrations/print.mddocs/integrations/pydantic.mddocs/integrations/pytest.mddocs/integrations/stripe.mddocs/integrations/structlog.mddocs/integrations/system-metrics.mddocs/integrations/web-frameworks/aiohttp.mddocs/integrations/web-frameworks/asgi.mddocs/integrations/web-frameworks/django.mddocs/integrations/web-frameworks/fastapi.mddocs/integrations/web-frameworks/flask.mddocs/integrations/web-frameworks/gunicorn.mddocs/integrations/web-frameworks/index.mddocs/integrations/web-frameworks/starlette.mddocs/integrations/web-frameworks/wsgi.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
pydantic/logfire(manual)pydantic/pydantic-ai(manual)pydantic/pydantic(auto-detected)
d492298 to
4107e69
Compare
There was a problem hiding this comment.
All reported issues were addressed
Confidence score: 5/5
- Safe to merge after the addressed issues were fixed.
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
4107e69 to
5e57cce
Compare
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
docs/integrations/llms/litellm.md (1)
95-97: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win
openinference-instrumentation-litellmis an OpenInference package, not an OpenTelemetry-owned one.Labeling it "Underlying OpenTelemetry package" overstates the relationship — it's an Arize-maintained OpenInference instrumentation that emits OpenTelemetry-compatible spans, distinct from
opentelemetry-python-contribpackages (e.g., the Celery instrumentation referenced elsewhere uses the correct label). Consider "Underlying OpenInference package" for accuracy.✏️ Proposed fix
- API reference: [`logfire.instrument_litellm()`][logfire.Logfire.instrument_litellm] -- Underlying OpenTelemetry package: +- Underlying OpenInference package: [`openinference-instrumentation-litellm`](https://pypi.org/project/openinference-instrumentation-litellm/)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/litellm.md` around lines 95 - 97, Update the package label in the LiteLLM integration documentation from “Underlying OpenTelemetry package” to “Underlying OpenInference package,” leaving the linked package and surrounding API reference unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/integrations/databases/asyncpg.md`:
- Line 49: Update the asyncpg connection examples to use a loopback destination,
replacing every client-facing 0.0.0.0 URL with 127.0.0.1 or localhost
consistently, including the repeated example later in the document.
In `@docs/integrations/llms/claude-agent-sdk.md`:
- Around line 8-17: Update the introductory capture description and the “What
you'll capture” list to qualify tool-call and conversation tracing as applying
to ClaudeSDKClient, and explicitly note that top-level claude_agent_sdk.query()
is not instrumented. Keep the existing trace and span explanations intact while
avoiding an unconditional promise that every SDK API receives these traces.
In `@docs/integrations/web-frameworks/fastapi.md`:
- Around line 15-18: Update the FastAPI guide near the captured arguments and
validation errors list to explicitly warn that these values are sent to Logfire
and may include secrets or personally identifiable information. Add a concise
reference to scrubbing or request_attributes_mapper for redaction, following the
existing asyncpg guide pattern.
In `@docs/integrations/web-frameworks/index.md`:
- Line 7: Update the introductory sentence around the “every request” claim to
qualify that only instrumented requests appear in Logfire, or explicitly note
that excluded requests do not produce spans. Keep the existing description of
trace details and framework setup unchanged.
---
Nitpick comments:
In `@docs/integrations/llms/litellm.md`:
- Around line 95-97: Update the package label in the LiteLLM integration
documentation from “Underlying OpenTelemetry package” to “Underlying
OpenInference package,” leaving the linked package and surrounding API reference
unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: b9e998ab-6f3d-4fb4-829d-a3036ef0d08e
📒 Files selected for processing (45)
docs/integrations/aws-lambda.mddocs/integrations/databases/asyncpg.mddocs/integrations/databases/bigquery.mddocs/integrations/databases/mysql.mddocs/integrations/databases/psycopg.mddocs/integrations/databases/pymongo.mddocs/integrations/databases/redis.mddocs/integrations/databases/sqlalchemy.mddocs/integrations/databases/sqlite3.mddocs/integrations/event-streams/airflow.mddocs/integrations/event-streams/celery.mddocs/integrations/event-streams/faststream.mddocs/integrations/http-clients/aiohttp.mddocs/integrations/http-clients/httpx.mddocs/integrations/http-clients/requests.mddocs/integrations/index.mddocs/integrations/llms/anthropic.mddocs/integrations/llms/claude-agent-sdk.mddocs/integrations/llms/dspy.mddocs/integrations/llms/google-genai.mddocs/integrations/llms/langchain.mddocs/integrations/llms/litellm.mddocs/integrations/llms/llamaindex.mddocs/integrations/llms/magentic.mddocs/integrations/llms/mcp.mddocs/integrations/llms/mirascope.mddocs/integrations/llms/openai.mddocs/integrations/llms/pydanticai.mddocs/integrations/logging.mddocs/integrations/loguru.mddocs/integrations/print.mddocs/integrations/pydantic.mddocs/integrations/pytest.mddocs/integrations/stripe.mddocs/integrations/structlog.mddocs/integrations/system-metrics.mddocs/integrations/web-frameworks/aiohttp.mddocs/integrations/web-frameworks/asgi.mddocs/integrations/web-frameworks/django.mddocs/integrations/web-frameworks/fastapi.mddocs/integrations/web-frameworks/flask.mddocs/integrations/web-frameworks/gunicorn.mddocs/integrations/web-frameworks/index.mddocs/integrations/web-frameworks/starlette.mddocs/integrations/web-frameworks/wsgi.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
pydantic/logfire(manual)pydantic/pydantic-ai(manual)pydantic/pydantic(auto-detected)
🚧 Files skipped from review as they are similar to previous changes (29)
- docs/integrations/databases/redis.md
- docs/integrations/llms/mcp.md
- docs/integrations/llms/langchain.md
- docs/integrations/llms/llamaindex.md
- docs/integrations/event-streams/airflow.md
- docs/integrations/llms/google-genai.md
- docs/integrations/web-frameworks/aiohttp.md
- docs/integrations/llms/dspy.md
- docs/integrations/aws-lambda.md
- docs/integrations/print.md
- docs/integrations/event-streams/faststream.md
- docs/integrations/stripe.md
- docs/integrations/databases/bigquery.md
- docs/integrations/web-frameworks/asgi.md
- docs/integrations/web-frameworks/flask.md
- docs/integrations/web-frameworks/gunicorn.md
- docs/integrations/system-metrics.md
- docs/integrations/web-frameworks/wsgi.md
- docs/integrations/llms/anthropic.md
- docs/integrations/structlog.md
- docs/integrations/index.md
- docs/integrations/llms/mirascope.md
- docs/integrations/http-clients/requests.md
- docs/integrations/pytest.md
- docs/integrations/databases/mysql.md
- docs/integrations/pydantic.md
- docs/integrations/web-frameworks/django.md
- docs/integrations/http-clients/aiohttp.md
- docs/integrations/http-clients/httpx.md
There was a problem hiding this comment.
Review completed against the latest diff
Confidence score: 5/5
- Safe to merge after the addressed issues were fixed.
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
5e57cce to
a5fb629
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/integrations/event-streams/celery.md (1)
51-73: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
add.delay(42, 50)at module scope still auto-enqueues on import.Since this call lives directly in
tasks.py, runningcelery -A tasks workerimports the module and fires a task as a side effect. Move it to a separate producer script/if __name__ == "__main__":block.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/event-streams/celery.md` around lines 51 - 73, Move the module-scope add.delay(42, 50) call out of tasks.py so importing the Celery app does not enqueue a task. Place it in a separate producer script or an if __name__ == "__main__": block while preserving the existing task definition and worker startup flow.docs/integrations/loguru.md (1)
52-79: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winSection order breaks the standardized flow.
Every other reviewed guide orders sections Verify → Troubleshooting → Advanced → Reference, but here "## Advanced" (line 59) comes before "## Troubleshooting" (line 71). Move Troubleshooting ahead of Advanced for consistency with the rest of the guide set.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/loguru.md` around lines 52 - 79, Reorder the sections in the Loguru integration guide so “## Troubleshooting” appears immediately after “## Verify it worked” and before “## Advanced”; preserve the existing section content and keep “## Reference” last.
♻️ Duplicate comments (3)
docs/integrations/event-streams/airflow.md (1)
37-41: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winDocument the required
apache-airflow[otel]extra.Airflow's OpenTelemetry traces/metrics support requires installing with the
otelextra (pip install 'apache-airflow[otel]'); without it, none of theotel_*settings below will do anything. This section still only says Logfire itself doesn't need installing in the Airflow environment — it doesn't mention the Airflow-side extra.📝 Proposed fix
## Installation -Airflow has no separate Logfire extra: its OpenTelemetry support is built in. This page configures -Airflow directly, so you don't need to install `logfire` in your Airflow environment. Everything below -is set through environment variables and `airflow.cfg`. +Airflow has no separate Logfire extra: its OpenTelemetry support is built in, but it does need the +`otel` extra installed: `pip install 'apache-airflow[otel]'`. You don't need to install `logfire` in +your Airflow environment; everything below is set through environment variables and `airflow.cfg`.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/event-streams/airflow.md` around lines 37 - 41, Update the Installation section of the Airflow integration documentation to state that Airflow must be installed with its otel extra, including the command pip install 'apache-airflow[otel]'. Keep the existing guidance that Logfire itself does not need to be installed in the Airflow environment.docs/integrations/web-frameworks/fastapi.md (1)
15-18: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick winSensitive Data Exposure (CWE-359)
Reachability: External
Still missing disclosure that captured arguments/errors are sent to Logfire.
The list states parsed arguments and validation errors are captured but doesn't warn these values are transmitted to Logfire and may contain secrets or PII, unlike the asyncpg guide's pattern for query parameters. As per coding guidelines, public docs must state such consequences plainly.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/web-frameworks/fastapi.md` around lines 15 - 18, Update the FastAPI instrumentation data-capture list to explicitly disclose that parsed endpoint arguments and validation errors are sent to Logfire and may contain secrets or personally identifiable information; preserve the existing items while adding clear warning language near those entries.Source: Coding guidelines
docs/integrations/event-streams/celery.md (1)
35-37: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winStill uses
worker_initinstead ofworker_process_init.
worker_initfires in the parent process before the prefork pool forks; initializing Logfire's exporters there risks inherited fork-unsafe state (deadlocked/lost spans) in the default worker pool.worker_process_initruns inside each forked child and is the standard, fork-safe hook.📝 Proposed fix
-Call `logfire.configure()`, then [`logfire.instrument_celery()`][logfire.Logfire.instrument_celery] to -record every task. Call both inside Celery's `worker_init` signal so they run once each worker process -starts. +Call `logfire.configure()`, then [`logfire.instrument_celery()`][logfire.Logfire.instrument_celery] to +record every task. Call both inside Celery's `worker_process_init` signal so they run once each worker +process starts (`worker_init` runs in the parent process before workers are forked, and is not safe +for this).-from celery.signals import worker_init +from celery.signals import worker_process_init ... -@worker_init.connect() # (1)! +@worker_process_init.connect() # (1)! def init_worker(*args, **kwargs): logfire.configure(service_name='worker') # (2)! logfire.instrument_celery()Also applies to: 51-61
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/event-streams/celery.md` around lines 35 - 37, Update the Celery integration instructions to use Celery’s worker_process_init signal instead of worker_init for calling logfire.configure() and logfire.instrument_celery(), ensuring both run once inside each forked worker process. Apply the same change to the corresponding example referenced near the later section.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/integrations/databases/pymongo.md`:
- Line 45: Update the MongoDB Docker command in the local setup example to bind
port 27017 specifically to 127.0.0.1, preventing unauthenticated MongoDB access
from remote host interfaces.
In `@docs/integrations/llms/pydanticai.md`:
- Line 73: Add a reference-style link definition for
pydantic_ai.models.KnownModelName in the documentation page, targeting the
appropriate Pydantic AI API or model-name documentation. Keep the existing
reference link text and surrounding example unchanged.
In `@docs/integrations/logging.md`:
- Line 8: Add the missing [logging] reference definition in
docs/integrations/logging.md, targeting Python’s official logging documentation,
so the existing [logging][] reference near the introduction resolves correctly.
---
Outside diff comments:
In `@docs/integrations/event-streams/celery.md`:
- Around line 51-73: Move the module-scope add.delay(42, 50) call out of
tasks.py so importing the Celery app does not enqueue a task. Place it in a
separate producer script or an if __name__ == "__main__": block while preserving
the existing task definition and worker startup flow.
In `@docs/integrations/loguru.md`:
- Around line 52-79: Reorder the sections in the Loguru integration guide so “##
Troubleshooting” appears immediately after “## Verify it worked” and before “##
Advanced”; preserve the existing section content and keep “## Reference” last.
---
Duplicate comments:
In `@docs/integrations/event-streams/airflow.md`:
- Around line 37-41: Update the Installation section of the Airflow integration
documentation to state that Airflow must be installed with its otel extra,
including the command pip install 'apache-airflow[otel]'. Keep the existing
guidance that Logfire itself does not need to be installed in the Airflow
environment.
In `@docs/integrations/event-streams/celery.md`:
- Around line 35-37: Update the Celery integration instructions to use Celery’s
worker_process_init signal instead of worker_init for calling
logfire.configure() and logfire.instrument_celery(), ensuring both run once
inside each forked worker process. Apply the same change to the corresponding
example referenced near the later section.
In `@docs/integrations/web-frameworks/fastapi.md`:
- Around line 15-18: Update the FastAPI instrumentation data-capture list to
explicitly disclose that parsed endpoint arguments and validation errors are
sent to Logfire and may contain secrets or personally identifiable information;
preserve the existing items while adding clear warning language near those
entries.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 26878d11-907a-4a35-b006-d439316dc7c8
📒 Files selected for processing (45)
docs/integrations/aws-lambda.mddocs/integrations/databases/asyncpg.mddocs/integrations/databases/bigquery.mddocs/integrations/databases/mysql.mddocs/integrations/databases/psycopg.mddocs/integrations/databases/pymongo.mddocs/integrations/databases/redis.mddocs/integrations/databases/sqlalchemy.mddocs/integrations/databases/sqlite3.mddocs/integrations/event-streams/airflow.mddocs/integrations/event-streams/celery.mddocs/integrations/event-streams/faststream.mddocs/integrations/http-clients/aiohttp.mddocs/integrations/http-clients/httpx.mddocs/integrations/http-clients/requests.mddocs/integrations/index.mddocs/integrations/llms/anthropic.mddocs/integrations/llms/claude-agent-sdk.mddocs/integrations/llms/dspy.mddocs/integrations/llms/google-genai.mddocs/integrations/llms/langchain.mddocs/integrations/llms/litellm.mddocs/integrations/llms/llamaindex.mddocs/integrations/llms/magentic.mddocs/integrations/llms/mcp.mddocs/integrations/llms/mirascope.mddocs/integrations/llms/openai.mddocs/integrations/llms/pydanticai.mddocs/integrations/logging.mddocs/integrations/loguru.mddocs/integrations/print.mddocs/integrations/pydantic.mddocs/integrations/pytest.mddocs/integrations/stripe.mddocs/integrations/structlog.mddocs/integrations/system-metrics.mddocs/integrations/web-frameworks/aiohttp.mddocs/integrations/web-frameworks/asgi.mddocs/integrations/web-frameworks/django.mddocs/integrations/web-frameworks/fastapi.mddocs/integrations/web-frameworks/flask.mddocs/integrations/web-frameworks/gunicorn.mddocs/integrations/web-frameworks/index.mddocs/integrations/web-frameworks/starlette.mddocs/integrations/web-frameworks/wsgi.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
pydantic/logfire(manual)pydantic/pydantic-ai(manual)pydantic/pydantic(auto-detected)
🚧 Files skipped from review as they are similar to previous changes (30)
- docs/integrations/print.md
- docs/integrations/web-frameworks/flask.md
- docs/integrations/web-frameworks/aiohttp.md
- docs/integrations/databases/bigquery.md
- docs/integrations/index.md
- docs/integrations/databases/redis.md
- docs/integrations/llms/dspy.md
- docs/integrations/web-frameworks/index.md
- docs/integrations/llms/claude-agent-sdk.md
- docs/integrations/stripe.md
- docs/integrations/http-clients/requests.md
- docs/integrations/structlog.md
- docs/integrations/llms/mcp.md
- docs/integrations/llms/llamaindex.md
- docs/integrations/http-clients/httpx.md
- docs/integrations/aws-lambda.md
- docs/integrations/pydantic.md
- docs/integrations/llms/anthropic.md
- docs/integrations/llms/langchain.md
- docs/integrations/system-metrics.md
- docs/integrations/web-frameworks/gunicorn.md
- docs/integrations/event-streams/faststream.md
- docs/integrations/llms/google-genai.md
- docs/integrations/web-frameworks/asgi.md
- docs/integrations/pytest.md
- docs/integrations/http-clients/aiohttp.md
- docs/integrations/databases/mysql.md
- docs/integrations/llms/mirascope.md
- docs/integrations/databases/asyncpg.md
- docs/integrations/web-frameworks/wsgi.md
a5fb629 to
6086d04
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/integrations/databases/sqlalchemy.md (1)
28-55: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winMake the runnable examples execute a query.
Both examples only create and instrument engines;
python main.pyexits without producing a query span. Add a minimalselect 1query to each example, or describe them as setup-only examples. The suppliedtests/otel_integrations/test_sqlalchemy.py:397-416confirms that query execution is required for the captured spans.Suggested addition
-from sqlalchemy import create_engine +from sqlalchemy import create_engine, text ... logfire.instrument_sqlalchemy(engine=engine) +with engine.connect() as connection: + connection.execute(text('select 1'))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/databases/sqlalchemy.md` around lines 28 - 55, Update both the “One engine” and “Multiple engines” examples after instrumentation to execute a minimal SQLAlchemy `select 1` query, ensuring each runnable example produces a query span. Keep the existing engine setup and instrumentation unchanged.
♻️ Duplicate comments (1)
docs/integrations/stripe.md (1)
112-116: 🔒 Security & Privacy | 🟠 MajorSensitive Data Exposure (CWE-200): Exposure of Sensitive Information to an Unauthorized Actor
Reachability: External
Scope the logging handler to Stripe’s logger.
The accompanying example uses
basicConfig(), which configures the root logger when no handlers exist and can forward unrelated applicationINFOlogs—and possible sensitive data—to Logfire. Configurelogging.getLogger('stripe')directly, or explicitly document the global scope.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/stripe.md` around lines 112 - 116, Update the Stripe logging documentation and example to configure only logging.getLogger('stripe') rather than using basicConfig(), so unrelated application INFO logs are not forwarded. If global logging must remain, explicitly document that scope and its implications.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/integrations/event-streams/celery.md`:
- Line 46: Update the Redis docker run example to bind port 6379 explicitly to
loopback using 127.0.0.1, preventing exposure on all host interfaces. Do not add
remote-access controls unless the example is intended to support remote access.
In `@docs/integrations/llms/openai.md`:
- Around line 226-227: Define the missing
logfire.Logfire.instrument_openai_agents reference label used by the links near
the “instrument_openai_agents() API reference” mentions. Add a matching valid
API-reference target, or update both references to reuse an existing valid
target, ensuring the links render correctly.
---
Outside diff comments:
In `@docs/integrations/databases/sqlalchemy.md`:
- Around line 28-55: Update both the “One engine” and “Multiple engines”
examples after instrumentation to execute a minimal SQLAlchemy `select 1` query,
ensuring each runnable example produces a query span. Keep the existing engine
setup and instrumentation unchanged.
---
Duplicate comments:
In `@docs/integrations/stripe.md`:
- Around line 112-116: Update the Stripe logging documentation and example to
configure only logging.getLogger('stripe') rather than using basicConfig(), so
unrelated application INFO logs are not forwarded. If global logging must
remain, explicitly document that scope and its implications.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 45bffa0a-2d9e-4528-9b9b-341df1d3d83e
📒 Files selected for processing (45)
docs/integrations/aws-lambda.mddocs/integrations/databases/asyncpg.mddocs/integrations/databases/bigquery.mddocs/integrations/databases/mysql.mddocs/integrations/databases/psycopg.mddocs/integrations/databases/pymongo.mddocs/integrations/databases/redis.mddocs/integrations/databases/sqlalchemy.mddocs/integrations/databases/sqlite3.mddocs/integrations/event-streams/airflow.mddocs/integrations/event-streams/celery.mddocs/integrations/event-streams/faststream.mddocs/integrations/http-clients/aiohttp.mddocs/integrations/http-clients/httpx.mddocs/integrations/http-clients/requests.mddocs/integrations/index.mddocs/integrations/llms/anthropic.mddocs/integrations/llms/claude-agent-sdk.mddocs/integrations/llms/dspy.mddocs/integrations/llms/google-genai.mddocs/integrations/llms/langchain.mddocs/integrations/llms/litellm.mddocs/integrations/llms/llamaindex.mddocs/integrations/llms/magentic.mddocs/integrations/llms/mcp.mddocs/integrations/llms/mirascope.mddocs/integrations/llms/openai.mddocs/integrations/llms/pydanticai.mddocs/integrations/logging.mddocs/integrations/loguru.mddocs/integrations/print.mddocs/integrations/pydantic.mddocs/integrations/pytest.mddocs/integrations/stripe.mddocs/integrations/structlog.mddocs/integrations/system-metrics.mddocs/integrations/web-frameworks/aiohttp.mddocs/integrations/web-frameworks/asgi.mddocs/integrations/web-frameworks/django.mddocs/integrations/web-frameworks/fastapi.mddocs/integrations/web-frameworks/flask.mddocs/integrations/web-frameworks/gunicorn.mddocs/integrations/web-frameworks/index.mddocs/integrations/web-frameworks/starlette.mddocs/integrations/web-frameworks/wsgi.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
pydantic/logfire(manual)pydantic/pydantic-ai(manual)pydantic/pydantic(auto-detected)
🚧 Files skipped from review as they are similar to previous changes (28)
- docs/integrations/web-frameworks/index.md
- docs/integrations/web-frameworks/flask.md
- docs/integrations/aws-lambda.md
- docs/integrations/llms/dspy.md
- docs/integrations/llms/mirascope.md
- docs/integrations/http-clients/aiohttp.md
- docs/integrations/llms/google-genai.md
- docs/integrations/pydantic.md
- docs/integrations/structlog.md
- docs/integrations/web-frameworks/wsgi.md
- docs/integrations/index.md
- docs/integrations/print.md
- docs/integrations/llms/anthropic.md
- docs/integrations/web-frameworks/aiohttp.md
- docs/integrations/databases/bigquery.md
- docs/integrations/llms/claude-agent-sdk.md
- docs/integrations/databases/asyncpg.md
- docs/integrations/event-streams/airflow.md
- docs/integrations/system-metrics.md
- docs/integrations/web-frameworks/django.md
- docs/integrations/databases/mysql.md
- docs/integrations/databases/redis.md
- docs/integrations/http-clients/httpx.md
- docs/integrations/web-frameworks/asgi.md
- docs/integrations/llms/llamaindex.md
- docs/integrations/llms/mcp.md
- docs/integrations/llms/langchain.md
- docs/integrations/web-frameworks/gunicorn.md
6086d04 to
376cb4a
Compare
In-place improvements to every integration guide — no pages move or change URLs. Each page now opens with what you'll capture, glosses observability terms (span, trace, OTLP) at first use, spells out acronyms, uses consistent house style (sentence-case headings, US spelling, no hype), and ends with a Verify / Troubleshooting section where relevant. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
376cb4a to
c3ae3d1
Compare
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/integrations/web-frameworks/starlette.md (1)
42-64: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
hl_lineshighlights blank lines instead of the instrumentation calls.Counting the fenced block's internal lines: line 8 is
logfire.configure()and line 16 islogfire.instrument_starlette(app)— the two calls this guide tells readers to add.hl_lines="7 14"instead highlights two blank lines just before those calls. This defeats the PR's stated goal of highlighting the primary code change in examples (compare fastapi.md'shl_lines="7-8", which correctly targets itsconfigure()/instrument_fastapi(app)pair).🐛 Proposed fix
-```py title="main.py" hl_lines="7 14" skip-run="true" skip-reason="server-start" +```py title="main.py" hl_lines="8 16" skip-run="true" skip-reason="server-start"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/web-frameworks/starlette.md` around lines 42 - 64, Update the Starlette example’s fenced-code metadata to set hl_lines to 8 and 16, highlighting logfire.configure() and logfire.instrument_starlette(app) rather than the preceding blank lines.
♻️ Duplicate comments (2)
docs/integrations/event-streams/celery.md (2)
35-37: 🩺 Stability & Availability | 🟠 MajorInitialize tracing in
worker_process_init, notworker_init.
worker_initis dispatched before the worker starts, whileworker_process_initis dispatched in each pool child process. The current instructions therefore do not initialize tracing once per worker process and can leave forked workers with inherited exporter state. (docs.celeryq.dev)This reintroduces the previously reported issue; update the prose, imports, decorator, and troubleshooting text consistently.
Also applies to: 75-76, 92-95
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/event-streams/celery.md` around lines 35 - 37, Update the Celery tracing setup documentation to use the worker_process_init signal instead of worker_init, including the signal import, decorator, and all troubleshooting references. Ensure logfire.configure() and logfire.instrument_celery() are described and shown as running once in each pool child process, with surrounding prose and examples kept consistent.
75-80: 🗄️ Data Integrity & Integration | 🟠 MajorKeep the producer call out of
tasks.py.The example still executes
add.delay(42, 50)at module import while the worker is started withcelery -A tasks worker, so importing the worker module can enqueue an unintended task. Move the trigger to a separate producer script or guard it behind an explicit command.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/event-streams/celery.md` around lines 75 - 80, Update the Celery example around the add.delay(42, 50) trigger so importing the tasks.py worker module never enqueues a task. Move the producer call into a separate producer script or protect it behind an explicit command, while preserving the worker startup flow and documented task-trigger behavior.
🧹 Nitpick comments (3)
docs/integrations/databases/sqlalchemy.md (1)
2-6: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winTitle/H1 pattern differs from sibling guides.
Every other guide in this batch uses a colon-descriptor front-matter title (e.g. "Instrument Psycopg: see every PostgreSQL query your app runs") paired with a bare product-name H1 (
# Psycopg). This page instead reuses "Instrument SQLAlchemy" for both, which stands out given the PR's goal of consistent house style across guides.✏️ Suggested alignment with sibling guides
-title: "Instrument SQLAlchemy" -description: "See every database query your app runs through SQLAlchemy (the SQL, how long it took, and which ones failed) as spans in Logfire." +title: "Instrument SQLAlchemy: see every database query your app runs" +description: "Add a few lines to your SQLAlchemy code and see every query in Logfire: the SQL statement, how long it took, and which ones failed." integration: otel --- -# Instrument SQLAlchemy +# SQLAlchemy🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/databases/sqlalchemy.md` around lines 2 - 6, Update the SQLAlchemy guide front-matter title to use the colon-descriptor pattern used by sibling integration guides, while keeping the H1 as the bare product name “SQLAlchemy.”docs/integrations/llms/litellm.md (1)
22-31: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a cost disclosure, matching sibling pages.
Sibling pages (magentic.md, pydanticai.md) explicitly disclose that provider calls made through the integration cost money on the user's provider account. This page's "Before you start" section lists the API key requirement but never states the cost consequence, which the coding guideline requires ("plainly state consequences such as ... cost ...").
✏️ Proposed addition
- **An API key for whichever model provider you call** (for example, `OPENAI_API_KEY` or `ANTHROPIC_API_KEY`). LiteLLM reads these from environment variables; see the [LiteLLM provider docs](https://docs.litellm.ai/docs/providers) for the variable each provider uses. + +LiteLLM calls the underlying model provider using your own API key, so each call costs money on +that provider account.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/litellm.md` around lines 22 - 31, Add a clear cost disclosure to the “Before you start” section of the LiteLLM integration documentation, alongside the API key requirement, stating that provider calls made through the integration may incur charges on the user’s provider account. Match the wording and placement used by the sibling integration pages.Source: Coding guidelines
docs/integrations/llms/openai.md (1)
23-33: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMissing cost disclosure, unlike sibling pages.
magentic.md and pydanticai.md explicitly state that calls made through the integration cost money on the provider account; this page's "Before you start" section omits that consequence despite the coding guideline requiring it.
✏️ Proposed addition
- **An OpenAI API key**, from your OpenAI dashboard at [platform.openai.com/api-keys](https://platform.openai.com/api-keys). The OpenAI SDK reads it from the `OPENAI_API_KEY` environment variable. + +Calls made through this integration use your own OpenAI account, so each call costs money on that +account.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/openai.md` around lines 23 - 33, Add a clear cost disclosure to the “Before you start” section of the OpenAI integration documentation, stating that integration calls incur charges against the user’s OpenAI account. Match the wording and placement used by the sibling magentic.md and pydanticai.md pages.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/integrations/event-streams/celery.md`:
- Around line 8-11: Update the trace-linking claim in the Celery integration
documentation to state that tasks appear alongside the request that enqueued
them only when both the Celery worker and enqueueing application are
instrumented. Keep the existing coverage claims for worker tasks and Celery beat
tasks unchanged.
- Around line 13-18: Add a concise warning beneath the “What you'll capture”
list explaining that Celery task arguments and errors are sent to and stored in
Logfire as span attributes and may contain secrets or personal data. Link to the
existing scrubbing guide and state its limitations.
In `@docs/integrations/event-streams/faststream.md`:
- Around line 30-35: Update the Installation section in faststream.md so the
install_logfire() snippet also installs FastStream’s otel extra, ensuring the
RedisTelemetryMiddleware example has its OpenTelemetry dependencies.
In `@docs/integrations/llms/anthropic.md`:
- Around line 8-18: Add a data-handling note near the “What you'll capture”
section explaining that captured prompts, responses, conversations, and tool
inputs are transmitted to Logfire, and link to the existing scrubbing or
redaction guidance for controlling sensitive content.
---
Outside diff comments:
In `@docs/integrations/web-frameworks/starlette.md`:
- Around line 42-64: Update the Starlette example’s fenced-code metadata to set
hl_lines to 8 and 16, highlighting logfire.configure() and
logfire.instrument_starlette(app) rather than the preceding blank lines.
---
Duplicate comments:
In `@docs/integrations/event-streams/celery.md`:
- Around line 35-37: Update the Celery tracing setup documentation to use the
worker_process_init signal instead of worker_init, including the signal import,
decorator, and all troubleshooting references. Ensure logfire.configure() and
logfire.instrument_celery() are described and shown as running once in each pool
child process, with surrounding prose and examples kept consistent.
- Around line 75-80: Update the Celery example around the add.delay(42, 50)
trigger so importing the tasks.py worker module never enqueues a task. Move the
producer call into a separate producer script or protect it behind an explicit
command, while preserving the worker startup flow and documented task-trigger
behavior.
---
Nitpick comments:
In `@docs/integrations/databases/sqlalchemy.md`:
- Around line 2-6: Update the SQLAlchemy guide front-matter title to use the
colon-descriptor pattern used by sibling integration guides, while keeping the
H1 as the bare product name “SQLAlchemy.”
In `@docs/integrations/llms/litellm.md`:
- Around line 22-31: Add a clear cost disclosure to the “Before you start”
section of the LiteLLM integration documentation, alongside the API key
requirement, stating that provider calls made through the integration may incur
charges on the user’s provider account. Match the wording and placement used by
the sibling integration pages.
In `@docs/integrations/llms/openai.md`:
- Around line 23-33: Add a clear cost disclosure to the “Before you start”
section of the OpenAI integration documentation, stating that integration calls
incur charges against the user’s OpenAI account. Match the wording and placement
used by the sibling magentic.md and pydanticai.md pages.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 1b3ea401-7034-427f-883c-ea128e499583
📒 Files selected for processing (45)
docs/integrations/aws-lambda.mddocs/integrations/databases/asyncpg.mddocs/integrations/databases/bigquery.mddocs/integrations/databases/mysql.mddocs/integrations/databases/psycopg.mddocs/integrations/databases/pymongo.mddocs/integrations/databases/redis.mddocs/integrations/databases/sqlalchemy.mddocs/integrations/databases/sqlite3.mddocs/integrations/event-streams/airflow.mddocs/integrations/event-streams/celery.mddocs/integrations/event-streams/faststream.mddocs/integrations/http-clients/aiohttp.mddocs/integrations/http-clients/httpx.mddocs/integrations/http-clients/requests.mddocs/integrations/index.mddocs/integrations/llms/anthropic.mddocs/integrations/llms/claude-agent-sdk.mddocs/integrations/llms/dspy.mddocs/integrations/llms/google-genai.mddocs/integrations/llms/langchain.mddocs/integrations/llms/litellm.mddocs/integrations/llms/llamaindex.mddocs/integrations/llms/magentic.mddocs/integrations/llms/mcp.mddocs/integrations/llms/mirascope.mddocs/integrations/llms/openai.mddocs/integrations/llms/pydanticai.mddocs/integrations/logging.mddocs/integrations/loguru.mddocs/integrations/print.mddocs/integrations/pydantic.mddocs/integrations/pytest.mddocs/integrations/stripe.mddocs/integrations/structlog.mddocs/integrations/system-metrics.mddocs/integrations/web-frameworks/aiohttp.mddocs/integrations/web-frameworks/asgi.mddocs/integrations/web-frameworks/django.mddocs/integrations/web-frameworks/fastapi.mddocs/integrations/web-frameworks/flask.mddocs/integrations/web-frameworks/gunicorn.mddocs/integrations/web-frameworks/index.mddocs/integrations/web-frameworks/starlette.mddocs/integrations/web-frameworks/wsgi.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
pydantic/logfire(manual)pydantic/pydantic-ai(manual)pydantic/pydantic(auto-detected)
🚧 Files skipped from review as they are similar to previous changes (30)
- docs/integrations/structlog.md
- docs/integrations/databases/asyncpg.md
- docs/integrations/web-frameworks/wsgi.md
- docs/integrations/llms/google-genai.md
- docs/integrations/logging.md
- docs/integrations/llms/mcp.md
- docs/integrations/web-frameworks/asgi.md
- docs/integrations/web-frameworks/flask.md
- docs/integrations/aws-lambda.md
- docs/integrations/llms/dspy.md
- docs/integrations/llms/llamaindex.md
- docs/integrations/web-frameworks/aiohttp.md
- docs/integrations/http-clients/requests.md
- docs/integrations/web-frameworks/gunicorn.md
- docs/integrations/system-metrics.md
- docs/integrations/pydantic.md
- docs/integrations/databases/redis.md
- docs/integrations/http-clients/aiohttp.md
- docs/integrations/databases/bigquery.md
- docs/integrations/event-streams/airflow.md
- docs/integrations/llms/claude-agent-sdk.md
- docs/integrations/llms/mirascope.md
- docs/integrations/llms/langchain.md
- docs/integrations/index.md
- docs/integrations/web-frameworks/index.md
- docs/integrations/print.md
- docs/integrations/web-frameworks/django.md
- docs/integrations/databases/mysql.md
- docs/integrations/stripe.md
- docs/integrations/http-clients/httpx.md
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
docs/integrations/loguru.md (1)
41-50: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winHighlight the instrumentation lines in the example.
Every other integration guide in this PR uses
hl_linesto spotlight thelogfire.configure()/ instrument call (per the PR's stated goal of highlighting the primary code change). This snippet's fenced block (py title="main.py") has no highlighting, breaking that consistency.✏️ Suggested fix
-```py title="main.py" +```py title="main.py" hl_lines="5 7" from loguru import logger import logfire logfire.configure() logger.configure(handlers=[logfire.loguru_handler()]) logger.info('Hello, {name}!', name='World')🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/loguru.md` around lines 41 - 50, Update the fenced Python example around logfire.configure() and logger.configure() to include hl_lines highlighting lines 5 and 7, matching the instrumentation highlighting convention used by the other integration guides.docs/integrations/llms/pydanticai.md (1)
75-86: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winStale TODO next to an already-embedded live trace.
Line 85's
TODO(app-verify): screenshot...is redundant — Lines 81-83 already embed a livepublic-traceviewer for this exact example, which is strictly better than a static screenshot. Worth removing the leftover TODO, and separately confirming that the hardcoded public-trace URL (a specific trace ID onlogfire-eu.pydantic.dev) is guaranteed to stay reachable/stable long-term rather than pointing at an ephemeral project trace.✏️ Proposed cleanup
/// public-trace | https://logfire-eu.pydantic.dev/public-trace/953848ba-11a8-4368-a21b-c9bda69a7f58?spanId=9026260034697d53 title: 'Logfire instrumentation of the agent run' /// - -<!-- TODO(app-verify): screenshot of the resulting Pydantic AI agent trace in the Live view -->🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/pydanticai.md` around lines 75 - 86, Remove the stale screenshot TODO beneath the embedded public trace in the “Verify it worked” section. Leave the existing `public-trace` embed unchanged; no additional URL changes are requested.docs/integrations/llms/magentic.md (1)
78-90: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove leftover screenshot block / redundant intro line, or drop the stale TODO.
Lines 82-87 duplicate the purpose of the new "Verify it worked" text with an old "The example above creates this in Logfire:" + static screenshot figure, and then Line 89 still asks for a fresh screenshot right below an existing one. This looks like a leftover from the pre-rewrite version that wasn't cleaned up during the restructure — confusing for anyone maintaining the page (is the shown screenshot current or does it still need capturing?).
✏️ Proposed cleanup
Run your program, then open the [Live view](../../guides/web-ui/live.md). Within a few seconds you'll see a trace for the `make_superhero` call. Click it to see the input arguments, the messages to and from the model, and a warning for each retry that was needed to produce valid output. -The example above creates this in Logfire: - -<figure markdown="span"> - { width="500" } - <figcaption>Magentic chatprompt-function call span and conversation</figcaption> -</figure> - <!-- TODO(app-verify): screenshot of the resulting Magentic trace in the Live view -->🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/magentic.md` around lines 78 - 90, Clean up the “Verify it worked” section by removing the redundant introductory sentence and stale static screenshot figure, and delete the adjacent TODO requesting another Magentic trace screenshot. Keep the verification instructions and relevant trace-description text intact.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/integrations/databases/sqlalchemy.md`:
- Around line 2-6: Update the H1 in the SQLAlchemy guide to use the short
product name “SQLAlchemy,” matching the sibling guides’ heading style, while
retaining the descriptive front-matter title.
---
Nitpick comments:
In `@docs/integrations/llms/magentic.md`:
- Around line 78-90: Clean up the “Verify it worked” section by removing the
redundant introductory sentence and stale static screenshot figure, and delete
the adjacent TODO requesting another Magentic trace screenshot. Keep the
verification instructions and relevant trace-description text intact.
In `@docs/integrations/llms/pydanticai.md`:
- Around line 75-86: Remove the stale screenshot TODO beneath the embedded
public trace in the “Verify it worked” section. Leave the existing
`public-trace` embed unchanged; no additional URL changes are requested.
In `@docs/integrations/loguru.md`:
- Around line 41-50: Update the fenced Python example around logfire.configure()
and logger.configure() to include hl_lines highlighting lines 5 and 7, matching
the instrumentation highlighting convention used by the other integration
guides.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 093b1091-9f8a-481e-aace-32c3c5cca721
📒 Files selected for processing (45)
docs/integrations/aws-lambda.mddocs/integrations/databases/asyncpg.mddocs/integrations/databases/bigquery.mddocs/integrations/databases/mysql.mddocs/integrations/databases/psycopg.mddocs/integrations/databases/pymongo.mddocs/integrations/databases/redis.mddocs/integrations/databases/sqlalchemy.mddocs/integrations/databases/sqlite3.mddocs/integrations/event-streams/airflow.mddocs/integrations/event-streams/celery.mddocs/integrations/event-streams/faststream.mddocs/integrations/http-clients/aiohttp.mddocs/integrations/http-clients/httpx.mddocs/integrations/http-clients/requests.mddocs/integrations/index.mddocs/integrations/llms/anthropic.mddocs/integrations/llms/claude-agent-sdk.mddocs/integrations/llms/dspy.mddocs/integrations/llms/google-genai.mddocs/integrations/llms/langchain.mddocs/integrations/llms/litellm.mddocs/integrations/llms/llamaindex.mddocs/integrations/llms/magentic.mddocs/integrations/llms/mcp.mddocs/integrations/llms/mirascope.mddocs/integrations/llms/openai.mddocs/integrations/llms/pydanticai.mddocs/integrations/logging.mddocs/integrations/loguru.mddocs/integrations/print.mddocs/integrations/pydantic.mddocs/integrations/pytest.mddocs/integrations/stripe.mddocs/integrations/structlog.mddocs/integrations/system-metrics.mddocs/integrations/web-frameworks/aiohttp.mddocs/integrations/web-frameworks/asgi.mddocs/integrations/web-frameworks/django.mddocs/integrations/web-frameworks/fastapi.mddocs/integrations/web-frameworks/flask.mddocs/integrations/web-frameworks/gunicorn.mddocs/integrations/web-frameworks/index.mddocs/integrations/web-frameworks/starlette.mddocs/integrations/web-frameworks/wsgi.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
pydantic/logfire(manual)pydantic/pydantic-ai(manual)pydantic/pydantic(auto-detected)
🚧 Files skipped from review as they are similar to previous changes (28)
- docs/integrations/web-frameworks/aiohttp.md
- docs/integrations/llms/dspy.md
- docs/integrations/web-frameworks/gunicorn.md
- docs/integrations/llms/anthropic.md
- docs/integrations/databases/bigquery.md
- docs/integrations/event-streams/faststream.md
- docs/integrations/stripe.md
- docs/integrations/llms/mirascope.md
- docs/integrations/http-clients/aiohttp.md
- docs/integrations/http-clients/requests.md
- docs/integrations/web-frameworks/index.md
- docs/integrations/structlog.md
- docs/integrations/web-frameworks/asgi.md
- docs/integrations/llms/llamaindex.md
- docs/integrations/http-clients/httpx.md
- docs/integrations/aws-lambda.md
- docs/integrations/web-frameworks/django.md
- docs/integrations/system-metrics.md
- docs/integrations/llms/claude-agent-sdk.md
- docs/integrations/index.md
- docs/integrations/web-frameworks/flask.md
- docs/integrations/databases/redis.md
- docs/integrations/databases/mysql.md
- docs/integrations/llms/mcp.md
- docs/integrations/event-streams/airflow.md
- docs/integrations/pydantic.md
- docs/integrations/llms/langchain.md
- docs/integrations/databases/asyncpg.md
Fix hl_lines to point at the actual instrumentation lines (django, starlette, faststream, claude-agent-sdk); correct the pytest CI auto-enable condition (CI must be true/1, not any non-empty string); add data-handling notes for Celery task arguments and Anthropic conversations; clarify that HTTP hooks run after built-in header capture; note the google-cloud-bigquery and OPENAI_API_KEY prerequisites; gloss spans/traces on the integrations index; US spelling fixes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Addressed the review feedback in A few I'm holding deliberately rather than silently applying:
Dismissed:
|
The 'Before you start' section was copy-pasted across 44 integration
pages in several drifting variants, all telling users to fetch a write
token from Project -> Settings -> Write tokens. That no longer matches
how the product onboards: the Add data wizard signs your machine in with
'logfire auth' (no token to copy for local dev) and treats the write
token as the production/CI credential.
Replace the duplicated blocks with a single {{ before_you_start() }}
macro (in docs/plugins/main.py, alongside install_logfire) that points
readers at the Add data wizard and resolves the Getting Started link
relative to each page. Pages with an extra requirement (model API key)
or a cost/version note keep that as a follow-on line.
Also removes the internal TODO(app-verify) screenshot placeholders.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… feedback) - Celery: initialize tracing in worker_process_init (weak=False), not worker_init, so the exporter's background thread is created after the prefork pool forks (matches the OpenTelemetry CeleryInstrumentor guidance). - Airflow: document the required apache-airflow[otel] extra. - FastStream: document the required faststream[otel] extra. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Addressed in
|
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/integrations/logging.md (1)
130-133: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winFilter only
urllib3DEBUG records.
not urllib3_filter.filter(record)rejects every record fromurllib3, including warnings and errors, despite the section promising to disable only DEBUG output. This can hide useful API and connection failures on the fallback path.- logfire_handler.fallback.addFilter(lambda record: not urllib3_filter.filter(record)) + logfire_handler.fallback.addFilter( + lambda record: not (urllib3_filter.filter(record) and record.levelno == logging.DEBUG) + )Apply the equivalent change to the
dictConfig()example.Also applies to: 150-153
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/logging.md` around lines 130 - 133, Update both fallback-handler examples, including the dictConfig() example, so their urllib3 filter excludes only records from the urllib3 logger at DEBUG level while allowing warnings and errors through. Replace the broad urllib3_filter negation in the fallback filtering logic without changing unrelated logging configuration.docs/integrations/llms/llamaindex.md (1)
13-14: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winBroken link syntax renders literally instead of hyperlinking "OpenLLMetry".
[OpenLLMetry]: [...]...on its own line, as a lazy-continuation of the paragraph starting on line 13, is not parsed as a Markdown link reference definition (ref defs can't interrupt an existing paragraph). It will render as literal text[OpenLLMetry]: ...instead of a link, which looks like a leftover formatting mistake.✏️ Proposed fix
We recommend instrumenting LlamaIndex with the OpenTelemetry instrumentation from -[OpenLLMetry]: [`opentelemetry-instrumentation-llamaindex`][opentelemetry-instrumentation-llamaindex]. +[OpenLLMetry][OpenLLMetry]: [`opentelemetry-instrumentation-llamaindex`][opentelemetry-instrumentation-llamaindex].🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/integrations/llms/llamaindex.md` around lines 13 - 14, Fix the Markdown reference definition for “OpenLLMetry” in the LlamaIndex documentation by placing it outside the preceding paragraph, with a blank line separating the paragraph from the reference definition. Preserve the existing link target and link text.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@docs/integrations/llms/llamaindex.md`:
- Around line 13-14: Fix the Markdown reference definition for “OpenLLMetry” in
the LlamaIndex documentation by placing it outside the preceding paragraph, with
a blank line separating the paragraph from the reference definition. Preserve
the existing link target and link text.
In `@docs/integrations/logging.md`:
- Around line 130-133: Update both fallback-handler examples, including the
dictConfig() example, so their urllib3 filter excludes only records from the
urllib3 logger at DEBUG level while allowing warnings and errors through.
Replace the broad urllib3_filter negation in the fallback filtering logic
without changing unrelated logging configuration.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 88a90ff4-0dd0-406e-a6c1-be288d110282
📒 Files selected for processing (45)
docs/integrations/aws-lambda.mddocs/integrations/databases/asyncpg.mddocs/integrations/databases/bigquery.mddocs/integrations/databases/mysql.mddocs/integrations/databases/psycopg.mddocs/integrations/databases/pymongo.mddocs/integrations/databases/redis.mddocs/integrations/databases/sqlalchemy.mddocs/integrations/databases/sqlite3.mddocs/integrations/event-streams/airflow.mddocs/integrations/event-streams/celery.mddocs/integrations/event-streams/faststream.mddocs/integrations/http-clients/aiohttp.mddocs/integrations/http-clients/httpx.mddocs/integrations/http-clients/requests.mddocs/integrations/index.mddocs/integrations/llms/anthropic.mddocs/integrations/llms/claude-agent-sdk.mddocs/integrations/llms/dspy.mddocs/integrations/llms/google-genai.mddocs/integrations/llms/langchain.mddocs/integrations/llms/litellm.mddocs/integrations/llms/llamaindex.mddocs/integrations/llms/magentic.mddocs/integrations/llms/mcp.mddocs/integrations/llms/mirascope.mddocs/integrations/llms/openai.mddocs/integrations/llms/pydanticai.mddocs/integrations/logging.mddocs/integrations/loguru.mddocs/integrations/print.mddocs/integrations/pydantic.mddocs/integrations/pytest.mddocs/integrations/stripe.mddocs/integrations/structlog.mddocs/integrations/system-metrics.mddocs/integrations/web-frameworks/aiohttp.mddocs/integrations/web-frameworks/asgi.mddocs/integrations/web-frameworks/django.mddocs/integrations/web-frameworks/fastapi.mddocs/integrations/web-frameworks/flask.mddocs/integrations/web-frameworks/gunicorn.mddocs/integrations/web-frameworks/starlette.mddocs/integrations/web-frameworks/wsgi.mddocs/plugins/main.py
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
pydantic/logfire(manual)pydantic/pydantic-ai(manual)pydantic/pydantic(auto-detected)
🚧 Files skipped from review as they are similar to previous changes (39)
- docs/integrations/aws-lambda.md
- docs/integrations/web-frameworks/aiohttp.md
- docs/integrations/web-frameworks/flask.md
- docs/integrations/databases/redis.md
- docs/integrations/http-clients/requests.md
- docs/integrations/event-streams/airflow.md
- docs/integrations/llms/claude-agent-sdk.md
- docs/integrations/llms/pydanticai.md
- docs/integrations/databases/sqlalchemy.md
- docs/integrations/http-clients/httpx.md
- docs/integrations/llms/dspy.md
- docs/integrations/web-frameworks/gunicorn.md
- docs/integrations/llms/langchain.md
- docs/integrations/databases/pymongo.md
- docs/integrations/web-frameworks/asgi.md
- docs/integrations/web-frameworks/django.md
- docs/integrations/system-metrics.md
- docs/integrations/llms/mcp.md
- docs/integrations/stripe.md
- docs/integrations/web-frameworks/fastapi.md
- docs/integrations/llms/anthropic.md
- docs/integrations/llms/mirascope.md
- docs/integrations/llms/litellm.md
- docs/integrations/event-streams/faststream.md
- docs/integrations/databases/psycopg.md
- docs/integrations/web-frameworks/starlette.md
- docs/integrations/llms/google-genai.md
- docs/integrations/llms/openai.md
- docs/integrations/http-clients/aiohttp.md
- docs/integrations/llms/magentic.md
- docs/integrations/event-streams/celery.md
- docs/integrations/web-frameworks/wsgi.md
- docs/integrations/databases/sqlite3.md
- docs/integrations/pytest.md
- docs/integrations/index.md
- docs/integrations/print.md
- docs/integrations/databases/mysql.md
- docs/integrations/databases/asyncpg.md
- docs/integrations/databases/bigquery.md
From an adversarial page-by-page audit against the SDK source: - Add data-handling/scrubbing notes to the DSPy, LangChain, and LiteLLM guides (they send full prompts and responses to Logfire, like Anthropic). - Fix hl_lines highlighting a blank line instead of the instrument call (ASGI, WSGI). - Match documented types/APIs in examples: Pydantic tags list (not tuple), DSPy 'pip install dspy' (not the legacy dspy-ai), Celery beat_init weak=False for consistency with the worker signal. - Small fixes: 'Reply in markdown.' typo (Anthropic, OpenAI); unversioned Flask docs link. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
In-place quality improvements to every integration guide. No pages move or change URLs — all edits are to existing pages at their current paths.
Each page now:
45 files, all under
docs/integrations/. Reviewable as a uniform sweep; happy to split by sub-area (LLMs / web frameworks / databases / …) if that's easier to review.🤖 Generated with Claude Code