feat(mcp): Add pagination parameters to get_cloud_sync_logs tool#888
Conversation
Add optional parameters to limit log output and prevent context window overflow: - max_lines: Maximum number of lines to return (defaults to 4000) - line_offset: Number of lines to skip from the beginning - from_tail: Return lines from the end instead of the beginning Validation ensures line_offset and from_tail cannot be used together. Truncation metadata is appended when logs are limited. Co-Authored-By: AJ Steers <aj@airbyte.io>
Original prompt from AJ Steers |
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
👋 Greetings, Airbyte Team Member!Here are some helpful tips and reminders for your convenience. Testing This PyAirbyte VersionYou can test this version of PyAirbyte using the following: # Run PyAirbyte CLI from this branch:
uvx --from 'git+https://github.com/airbytehq/PyAirbyte.git@devin/1764717892-add-log-pagination-params' pyairbyte --help
# Install PyAirbyte from this branch for development:
pip install 'git+https://github.com/airbytehq/PyAirbyte.git@devin/1764717892-add-log-pagination-params'Helpful ResourcesPR Slash CommandsAirbyte Maintainers can execute the following slash commands on your PR:
Community SupportQuestions? Join the #pyairbyte channel in our Slack workspace. |
📝 WalkthroughWalkthroughReturn type for get_cloud_sync_logs changed from raw string to a structured LogReadResult; new parameters (max_lines, from_tail, line_offset) with mutual-exclusion validation were added; missing-resource paths now raise AirbyteMissingResourceError; log slicing and metadata population implemented (default max 4000, 0 = unlimited). Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
airbyte/mcp/cloud_ops.py (2)
805-831: Nice parameter design! Consider adding validation for parameter ranges, wdyt?The new pagination parameters are well-defined with clear descriptions. The mutual exclusivity constraint is properly documented.
However, there's no validation to ensure
max_linesandline_offsetare non-negative integers when provided. Negative values could lead to confusing behavior (e.g.,max_lines=-10would result in empty output due to Python slicing semantics).Consider adding validation after line 838:
if line_offset is not None and from_tail: raise PyAirbyteInputError( message="Cannot specify both 'line_offset' and 'from_tail' parameters." ) + + if max_lines is not None and max_lines < 0: + raise PyAirbyteInputError( + message="Parameter 'max_lines' must be non-negative." + ) + + if line_offset is not None and line_offset < 0: + raise PyAirbyteInputError( + message="Parameter 'line_offset' must be non-negative." + )
888-899: Small precision fix needed for the offset check, wdyt?The truncation note logic is well-implemented and informative. However, there's a minor precision issue on line 896.
Line 896 uses
elif line_offset:which relies on truthiness checking. If a user explicitly passesline_offset=0, this condition would be falsy, and the truncation note would omit the offset information. Whileline_offset=0is effectively "no offset," if it's explicitly set, it would be more accurate to include it in the note.Consider this fix for precision:
- elif line_offset: + elif line_offset is not None: truncation_note += f" (offset: {line_offset})"This ensures the offset is shown whenever it's explicitly provided, even if it's 0.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
airbyte/mcp/cloud_ops.py(2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
airbyte/mcp/cloud_ops.py (1)
airbyte/exceptions.py (1)
PyAirbyteInputError(201-210)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (No Creds)
- GitHub Check: Pytest (Fast)
🔇 Additional comments (3)
airbyte/mcp/cloud_ops.py (3)
834-838: Validation logic looks solid!The mutual exclusivity check correctly prevents using
line_offsetwithfrom_tail=True, while sensibly allowingline_offsetwithfrom_tail=Falseorfrom_tail=None. The error message is clear.
845-851: Excellent improvement to error messages!The new specific error messages for missing sync jobs and attempts are much more informative than generic errors would be. They provide clear context to help users understand what went wrong.
873-886: Line limiting logic is correct!The slicing logic properly handles both tail-based and offset-based line selection:
- Tail mode correctly retrieves the last N lines
- Offset mode correctly skips the specified number of lines from the beginning
- The default of 4000 lines matches the parameter documentation
…c_logs Update the return type from str to LogReadResult with structured fields: - log_text: The log text content - log_text_start_line: 1-based line index of first line returned - log_text_line_count: Count of lines returned - total_log_lines_available: Total lines available for pagination Also convert error cases from string returns to proper exceptions. Co-Authored-By: AJ Steers <aj@airbyte.io>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
airbyte/mcp/cloud_ops.py (1)
818-844: Consider validating non-negative values formax_linesandline_offset?Negative values could lead to unexpected Python slicing behavior. For instance,
line_offset=-5would causelines[-5:...]which returns lines from the end rather than raising an error. Adding a quick validation alongside the mutual exclusivity check would make the API more robust, wdyt?# Validate that line_offset and from_tail are not both set if line_offset is not None and from_tail: raise PyAirbyteInputError( message="Cannot specify both 'line_offset' and 'from_tail' parameters." ) + if max_lines is not None and max_lines < 0: + raise PyAirbyteInputError( + message="'max_lines' must be a non-negative integer." + ) + if line_offset is not None and line_offset < 0: + raise PyAirbyteInputError( + message="'line_offset' must be a non-negative integer." + )
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
airbyte/mcp/cloud_ops.py(3 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (Fast)
- GitHub Check: Pytest (No Creds)
🔇 Additional comments (5)
airbyte/mcp/cloud_ops.py (5)
163-174: Nice addition of a structured result model!The
LogReadResultmodel is well-designed for pagination—havingtotal_log_lines_availablealongside the returned line count makes it easy for consumers to understand truncation and request additional pages.
847-851: Validation logic looks correct.The mutual exclusivity check properly handles the case where
from_tail=False(essentially a no-op), only raising whenfrom_tailis truthy alongside a setline_offset.
858-883: Improved error handling with proper exceptions.Switching from returning error strings to raising
AirbyteMissingResourceErroris a better pattern—consumers can now catch specific exceptions rather than parsing return values. Just a heads up that this is a breaking change for any existing callers that relied on string returns for error cases, wdyt if that's been considered?
889-896: Clean handling of the empty logs edge case.Returning a structured
LogReadResultwith zeros rather than an empty string maintains consistency with the normal flow.
898-919: Line slicing logic looks solid.The pagination math handles both head and tail modes correctly. The edge case where
line_offsetexceeds total lines gracefully returns an empty result with accurate metadata—nice touch. The 1-based conversion forlog_text_start_lineis also correct.
Aaron ("AJ") Steers (aaronsteers)
requested a review
from Aldo Gonzalez (aldogonzalez8)
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
Aldo Gonzalez (aldogonzalez8)
left a comment
Aldo Gonzalez (aldogonzalez8)
left a comment
There was a problem hiding this comment.
APPROVED
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
airbyte/mcp/cloud_ops.py (2)
907-928: Pagination logic looks solid, minor edge case to consider.The implementation handles both tail-reading and offset-reading well. One small edge case: if
line_offsetexceedstotal_lines, the result will havelog_text_line_count=0butlog_text_start_linewill beline_offset + 1(which is beyond the available lines). This might be slightly confusing but isn't technically wrong. WDYT about clampingstart_indextototal_linesin such cases, or is the current behavior intentional to signal "you asked for lines beyond what exists"?Also, after line 858's fix,
max_linescould beNone, but it's typed asintin the signature (line 819). Should it beint | Noneto match the runtime behavior?
850-850: Consider updating the docstring to mention pagination.The docstring could briefly note that logs are paginated by default (4000 lines) to prevent context overflow. WDYT about adding a sentence like "Returns paginated log results with a default limit of 4000 lines"?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
airbyte/mcp/cloud_ops.py(3 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
airbyte/mcp/cloud_ops.py (2)
airbyte/exceptions.py (2)
PyAirbyteInputError(201-210)AirbyteMissingResourceError(505-509)airbyte/cloud/sync_results.py (3)
SyncResult(218-495)get_attempts(338-352)get_full_log_text(182-214)
🪛 GitHub Actions: Generate Docs
airbyte/mcp/cloud_ops.py
[error] 858-858: SyntaxError: expected 'else' after 'if' expression (max_lines = None if max_lines = 0 else max_lines)
🪛 GitHub Actions: Run Linters
airbyte/mcp/cloud_ops.py
[error] 858-858: SyntaxError: Invalid assignment target at line 858. max_lines = None if max_lines = 0 else max_lines
[error] 858-858: SyntaxError: Expected 'else', found '=' in expression: max_lines = None if max_lines = 0 else max_lines
[error] 858-858: SyntaxError: The keyword is not allowed as a variable declaration name in: max_lines = None if max_lines = 0 else max_lines
[error] 858-858: SyntaxError: Simple statements must be separated by newlines or semicolons in the expression around line 858.
[error] Ruff check failed due to syntax errors in the codebase.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (All, Python 3.11, Windows)
🔇 Additional comments (5)
airbyte/mcp/cloud_ops.py (5)
163-174: LGTM! Nice structured result model.The
LogReadResultclass provides a clean way to return paginated logs with metadata. The 1-based line indexing aligns well with how most editors display line numbers.
818-849: Nice pagination parameters, but heads up on the breaking change.The new parameters are well-documented and the default of 4000 lines makes sense for preventing context overflow. Just noting that this changes the default behavior from returning all logs to capping at 4000 lines - existing users relying on complete logs might be surprised. WDYT about mentioning this in the docstring or release notes?
851-856: LGTM! Clean validation logic.Good use of
PyAirbyteInputErrorto enforce the mutual exclusivity constraint betweenline_offsetandfrom_tail. The error context is helpful for debugging.
865-889: LGTM! Much better error handling.Raising
AirbyteMissingResourceErrorinstead of returning error strings is a solid improvement. This makes errors more consistent and machine-readable, especially useful in an MCP context where structured errors are valuable.
896-905: LGTM! Good handling of the no-logs edge case.Returning a structured
LogReadResulteven when logs are empty maintains consistency with the new return type. The descriptive message inlog_textis clear and helpful.
The line 'max_lines = None if max_lines == 0 else max_lines' had a typo (= instead of ==) and was also redundant since the logic at line 912 already handles max_lines=0 by using total_lines instead. Co-Authored-By: AJ Steers <aj@airbyte.io>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
airbyte/mcp/cloud_ops.py (2)
818-828: Type annotation looks good, minor comment about default behavior.The
max_linesparameter has typeintwith a default of 4000, which means it will never beNoneat runtime. The logic at line 911 (max_lines or total_lines) correctly handles the0case for "no limit." Just noting that the comment on line 910 mentions "None" but that's unreachable given the type - would you like to simplify the comment to just mention0, wdyt?- # If max_lines is 0 or None, we return all lines. + # If max_lines is 0, we return all lines (no limit).
795-927: Consider adding unit tests for the pagination logic.The new pagination parameters introduce several code paths:
from_tail=Truewith variousmax_linesvaluesline_offsetwith edge cases (0, within range, exceeding total)max_lines=0for "no limit"- Empty logs scenario
- Validation of mutual exclusivity
These would benefit from unit test coverage to prevent regressions. Would you like me to help generate test cases for these scenarios, wdyt?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
airbyte/mcp/cloud_ops.py(3 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
airbyte/mcp/cloud_ops.py (3)
airbyte/exceptions.py (1)
AirbyteMissingResourceError(505-509)airbyte/_util/api_util.py (1)
get_connection(336-363)airbyte/cloud/sync_results.py (2)
get_attempts(338-352)get_full_log_text(182-214)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (No Creds)
- GitHub Check: Pytest (Fast)
🔇 Additional comments (6)
airbyte/mcp/cloud_ops.py (6)
163-174: Nice addition of a structured result model!The
LogReadResultmodel cleanly encapsulates all the pagination metadata, making it easier for callers to understand what portion of logs they're seeing. The 1-based indexing is well-documented. LGTM!
851-856: Mutual exclusivity validation looks solid.The check correctly prevents combining
line_offsetwithfrom_tail=Truewhile allowingfrom_tail=Falseto pass through. The error message is clear and includes helpful context. Nice work!
864-875: Nice improvement: using structured errors instead of string returns.The switch to
AirbyteMissingResourceErroraligns with the codebase pattern (e.g.,get_connectioninapi_util.py). This makes error handling more explicit and programmatic.Just want to confirm - since this changes the behavior from returning a string to raising an exception, have you verified that MCP tool consumers handle this appropriately, wdyt?
894-904: Good handling of the empty logs case.The placeholder message clearly communicates the lack of logs. One small thought: setting
log_text_start_line=1when there are zero lines feels slightly semantic (what's line 1 of 0 lines?), but it's consistent with the 1-based indexing convention and avoids any potential 0-index confusion. Totally fine as-is!
913-920: Line slicing logic is correct.The
from_tailbranch correctly calculates the start index and takes the last N lines. The offset branch handles the standard pagination case well.One edge case to note: when
line_offset >= total_lines, this returns an empty result withlog_text_start_line = line_offset + 1(which exceedstotal_log_lines_available). The metadata fields make this unambiguous, but you might consider adding a note in the docstring about this behavior - or is the current behavior intuitive enough, wdyt?
922-927: Clean structured return.The
LogReadResultprovides all the pagination metadata (log_text_line_countandtotal_log_lines_available) that callers need to understand truncation - much better than appending a text note. This keeps the log text clean while still communicating the context.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
airbyte/mcp/cloud_ops.py (1)
899-911: Consider making empty‑logs metadata and text more self‑consistentFor the no‑logs case you return a human‑friendly message in
log_textbutlog_text_line_count=0. That’s perfectly workable, but it does mean line_count doesn’t reflect the number of newline‑separated lines inlog_textitself.Would you consider either (a) returning an empty
log_textand relying on the metadata, or (b) settinglog_text_line_countto the actual line count of the placeholder message, so the fields always describe the text payload? wdyt?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
airbyte/mcp/cloud_ops.py(3 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
airbyte/mcp/cloud_ops.py (2)
airbyte/exceptions.py (2)
PyAirbyteInputError(201-210)AirbyteMissingResourceError(505-509)airbyte/cloud/sync_results.py (1)
get_full_log_text(182-214)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (No Creds)
- GitHub Check: Pytest (Fast)
🔇 Additional comments (3)
airbyte/mcp/cloud_ops.py (3)
163-177: LogReadResult shape looks solid and future‑proofThe model fields and docs line up nicely with the pagination behavior and give downstream callers enough metadata to reason about truncation; this structure seems good to ship as‑is, wdyt?
856-861: Input‑validation guard for mutually exclusive params looks goodThe mutual‑exclusion check for
line_offsetandfrom_tailis clear and usesPyAirbyteInputErrorconsistently with the rest of the module; once theeffective_from_tailrefactor is in place, this should continue to behave as intended, wdyt?
869-893: Nice upgrade to structured missing‑resource errorsRaising
AirbyteMissingResourceErrorfor missing sync jobs/attempts (including the specific(job, attempt)identifier) is a good improvement over returning plain strings and should make debugging from agents easier; seems solid as‑is, wdyt?
Co-Authored-By: AJ Steers <aj@airbyte.io>
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
airbyte/mcp/cloud_ops.py (2)
822-864: Clarify pagination param behavior and consider guarding against invalid inputsA couple of edge cases you might want to nail down here:
- Because
max_lines,from_tail, andline_offsetdon’t have Python-level defaults (=), they become required keyword-only params for direct Python callers even though Pydantic/Field provides MCP defaults. If anyone imports and callsget_cloud_sync_logs(...)directly today, this is a subtle breaking change. Do you want to add=4000,=None, and=Nonedefaults at the function level to keep the Python API backward-friendly, wdyt?- Negative
max_lines/line_offsetwould currently flow through and produce surprising slices/metadata (e.g., negative counts or “past the end” indexes). Would you be open to validatingmax_lines >= 0andline_offset >= 0up front with aPyAirbyteInputErrorso bad inputs fail loudly instead of behaving oddly, wdyt?The mutual-exclusion check and the “default tail when both unset” behavior look good and match the docstring.
#!/bin/bash # Inspect direct Python usages of get_cloud_sync_logs that might rely on old signature/defaults. rg -n "get_cloud_sync_logs\(" -C3
915-937: Pagination logic is solid, but truncation signaling and extreme offsets might need tighteningThe core slicing looks good—
max_lines == 0as “no limit”, honoringline_offseteven whentotal_lines < max_lines, and tail vs head behavior all make sense. A couple of remaining nits:
- When
line_offsetis greater than or equal tototal_lines,start_indexcan point past the end (e.g., 101 for a 100‑line log) and we returnlog_text_line_count == 0. Would clampingstart_indextototal_lines(or otherwise makinglog_text_start_linenever exceedtotal_log_lines_available + 1) make the metadata easier to reason about, wdyt?- The PR description mentions appending a
[Showing X of Y total lines]note when truncation occurs, but the current implementation just drops lines silently. Would you be open to appending a final summary line whenlen(selected_lines) < (total_lines - start_index)(orlen(selected_lines) < total_linesfor tail mode) so LLMs can reliably see that truncation happened, wdyt?- Given the combinatorics here (tail/head,
max_lines,line_offset,max_lines=0), would you consider adding a small unit-test matrix around this block (especially for: default call, small logs, large logs with truncation,line_offsetnear/overtotal_lines, andmax_lines=0), wdyt? I’d be happy to help sketch those out.
🧹 Nitpick comments (1)
airbyte/mcp/cloud_ops.py (1)
901-913: Align empty-log metadata with the returned message?In the “no logs” branch,
log_textcontains a human-readable message butlog_text_line_countandtotal_log_lines_availableare both 0. That’s defensible if we treat the message as metadata rather than “real” log lines, but it does slightly contradict the field docstring (“Count of lines we are returning”).Would it be clearer either to (a) return an empty
log_textand let consumers key off the0counts, or (b) keep the message but setlog_text_line_count(and maybetotal_log_lines_available) to match the actual line count oflog_text, wdyt?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
airbyte/mcp/cloud_ops.py(3 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-07-11T19:53:44.427Z
Learnt from: yohannj
Repo: airbytehq/PyAirbyte PR: 716
File: airbyte/logs.py:384-402
Timestamp: 2025-07-11T19:53:44.427Z
Learning: In the PyAirbyte project, when reviewing PRs, maintain clear separation of concerns. Don't suggest changes that are outside the scope of the PR's main objective, even if they would improve consistency or fix other issues. This helps with reviewing changes and potential reverts.
Applied to files:
airbyte/mcp/cloud_ops.py
🧬 Code graph analysis (1)
airbyte/mcp/cloud_ops.py (2)
airbyte/exceptions.py (2)
PyAirbyteInputError(201-210)AirbyteMissingResourceError(505-509)airbyte/cloud/sync_results.py (2)
get_attempts(338-352)get_full_log_text(182-214)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pytest (All, Python 3.10, Windows)
- GitHub Check: Pytest (All, Python 3.11, Windows)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
- GitHub Check: Pytest (No Creds)
- GitHub Check: Pytest (Fast)
🔇 Additional comments (2)
airbyte/mcp/cloud_ops.py (2)
163-178: LogReadResult shape looks appropriate for paginated log responsesThe fields and docstrings line up well with how you consume them later (job/attempt IDs, 1‑based start, counts, total). I don’t see issues with this model as-is, so I’d keep it in this form unless downstream use-cases surface new needs, wdyt?
871-895: No breaking change concern—exceptions are already the module pattern and distinguish different error scenariosThe three exception cases (missing job, missing attempts, missing specific attempt) are properly distinguished from the "no logs" case at line 905, which still returns a LogReadResult with a message. Using
AirbyteMissingResourceErrorfor missing resources is already established in this module (see lines 1100, 1114). No callers were found that depend on string parsing from these specific resource-not-found scenarios.Likely an incorrect or invalid review comment.
Aaron ("AJ") Steers (aaronsteers)
deleted the
devin/1764717892-add-log-pagination-params
branch
2 participants
Summary
Adds optional parameters to the
get_cloud_sync_logsMCP tool to prevent sync logs from overwhelming the context window. This addresses an issue where logs were returning ~8.2m tokens and filling up the context.New parameters:
max_lines: Maximum lines to return (defaults to 4000 if not specified)line_offset: Skip N lines from the beginning of logsfrom_tail: Return lines from the end instead of beginningValidation ensures
line_offsetandfrom_tailcannot be used together. When logs are truncated, metadata is appended showing how many lines were returned vs total.Review & Testing Checklist for Human
line_offsetexceeds total lines? Currently returns empty result with truncation note - verify this is acceptable UX.get_cloud_sync_logswith various parameter combinations (no params, max_lines only, from_tail=True, line_offset=100) against a real connection with logs.Notes
[Showing X of Y total lines]is appended to the log outputRequested by: AJ Steers (Aaron ("AJ") Steers (@aaronsteers))
Link to Devin run: https://app.devin.ai/sessions/2b0a9632ae694b73be67301524ed7a8d
Summary by CodeRabbit
New Features
Bug Fixes
✏️ Tip: You can customize this high-level summary in your review settings.