Skip to content

feat(blocks): enhance GithubListPullRequestsBlock with metadata and filters#13253

Draft
Abhi1992002 wants to merge 3 commits into
Significant-Gravitas:devfrom
Abhi1992002:feat/enhance-list-pull-requests-block
Draft

feat(blocks): enhance GithubListPullRequestsBlock with metadata and filters#13253
Abhi1992002 wants to merge 3 commits into
Significant-Gravitas:devfrom
Abhi1992002:feat/enhance-list-pull-requests-block

Conversation

@Abhi1992002
Copy link
Copy Markdown
Contributor

@Abhi1992002 Abhi1992002 commented May 31, 2026

Summary

Enhances GithubListPullRequestsBlock to expose richer PR metadata and add filtering/pagination support. The GitHub API already returns all this data — it was simply not being mapped through to the block output.

Changes to GithubListPullRequestsBlock

New Output Fields

Field Type Description
number int PR number
state str open / closed / merged
author str GitHub username of the PR creator
created_at str ISO 8601 creation timestamp
updated_at str ISO 8601 last-updated timestamp
merged_at `str None`
base_branch str Target branch (e.g. dev)
head_branch str Source branch
labels list[str] List of label names
draft bool Whether the PR is a draft

New Input Filters (all advanced=True to keep basic UI clean)

Field Type Default Description
state Literal["open","closed","all"] open Filter by PR state
since str "" ISO 8601 date — only return PRs created/updated at or after this time
base str "" Filter by target branch
head str "" Filter by source branch or user (e.g. username:branch)
sort Literal["created","updated","popularity","long-running"] created Sort order
direction Literal["asc","desc"] desc Sort direction
per_page int 30 Results per page (1–100). Set to 0 for automatic pagination (fetches all pages)

Auto-Pagination

Setting per_page=0 triggers automatic pagination — the block loops through all pages and returns every matching PR. Previously the block silently capped at GitHub's default of 30 results.

Backwards Compatibility

✅ Fully backwards compatible — existing agents using this block will continue to work. All new fields are additive; all new inputs have sensible defaults.

…ilters

Add enriched output fields and input filters to GithubListPullRequestsBlock:

Output fields added:
- number: PR number
- state: open/closed
- author: PR author username
- created_at / updated_at / merged_at: timestamps
- base_branch / head_branch: branch names
- labels: list of label names
- draft: whether the PR is a draft

Input filters added:
- state: filter by open/closed/all (default: open)
- since: ISO 8601 datetime to filter PRs created at or after

The GitHub API already returns all these fields; this change maps them
through to the block output and adds query params to the /pulls endpoint.
@Abhi1992002 Abhi1992002 requested a review from a team as a code owner May 31, 2026 03:44
@Abhi1992002 Abhi1992002 requested review from Bentlybro and kcze and removed request for a team May 31, 2026 03:44
@github-project-automation github-project-automation Bot moved this to 🆕 Needs initial review in AutoGPT development kanban May 31, 2026
@github-actions
Copy link
Copy Markdown
Contributor

This PR targets the master branch but does not come from dev or a hotfix/* branch.

Automatically setting the base branch to dev.

@github-actions github-actions Bot changed the base branch from master to dev May 31, 2026 03:44
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 31, 2026

Review Change Stack

Walkthrough

GithubListPullRequestsBlock now accepts state and since filters and returns enriched PR metadata including timestamps, author, branches, labels, and draft status. The implementation calls GitHub's pulls API with state and pagination options, parses and applies the since timestamp, and constructs detailed PR items. Tests and a reviewers type annotation are updated accordingly.

Changes

GitHub Pull Request Listing Enhancement

Layer / File(s) Summary
Input/Output Schema Updates
autogpt_platform/backend/backend/blocks/github/pull_requests.py
Input adds state (open/closed/all) and since (ISO 8601 timestamp); Output.PRItem expands from title/url to include number, state, author, created_at, updated_at, optional merged_at, base_branch, head_branch, labels, and draft; typing imports updated to include Optional.
PR Fetching and Filtering Implementation
autogpt_platform/backend/backend/blocks/github/pull_requests.py
list_prs signature extended with state, base, head, sort, direction, per_page, since; supports auto-pagination when per_page == 0; adds _parse_pr to build enriched PRItem and apply since filtering; run forwards new inputs.
Test Configuration Updates
autogpt_platform/backend/backend/blocks/github/pull_requests.py
Block description and test_input updated to include listing filters; both test_output entries updated to match the expanded PRItem schema.
Type Annotation Cleanup
autogpt_platform/backend/backend/blocks/github/pull_requests.py
GithubListPRReviewersBlock.list_reviewers return type annotation changed to a forward string reference to GithubListPRReviewersBlock.Output.ReviewerItem.
Whitespace
autogpt_platform/backend/backend/blocks/github/pull_requests.py
Minor trailing blank-line change.

🎯 3 (Moderate) | ⏱️ ~25 minutes

"🐰 I hopped through code with nimble feet,
Filters and metadata now meet,
Timestamps, authors, branches bright,
Pulls enriched and tests alight! 🥕"

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately and concisely describes the main enhancement to GithubListPullRequestsBlock by highlighting the addition of metadata exposure and input filters.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description check ✅ Passed The pull request description provides a clear and detailed explanation of the changes, documenting new output fields, input filters, auto-pagination behavior, and backwards compatibility.

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

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

❤️ Share

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

) -> list["GithubListPullRequestsBlock.Output.PRItem"]:
api = get_api(credentials)
pulls_url = repo_url + "/pulls"
pulls_url = repo_url + f"/pulls?state={state}&per_page=100"

This comment was marked as outdated.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 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 `@autogpt_platform/backend/backend/blocks/github/pull_requests.py`:
- Around line 39-46: The docs say the SchemaField since should filter PRs
"created/updated at or after" but the current filter only checks created_at;
modify the filter logic that currently compares created_at (the block around the
code checking created_at >= since) to instead include PRs where either
created_at >= since OR updated_at >= since (parse/compare both ISO timestamps
robustly and handle empty/default since value), or alternatively change the
since SchemaField description to only mention creation; prefer updating the
filter so both created_at and updated_at are considered (refer to the since
SchemaField and the function/block that currently filters on created_at).
- Around line 2-3: Remove the unused import "timezone" from the import statement
at the top of the module; the file only needs "datetime" and the typing imports
(Literal, Optional) and handles timezone parsing via string replacement +
fromisoformat, so delete the "timezone" name from the line that currently reads
"from datetime import datetime, timezone" to avoid an unused import.
🪄 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

Run ID: e11b7830-7f35-4b4b-bca2-df960a23655c

📥 Commits

Reviewing files that changed from the base of the PR and between a59ff3c and 7e1fec7.

📒 Files selected for processing (1)
  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📜 Review details
⏰ 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). (16)
  • GitHub Check: check API types
  • GitHub Check: Seer Code Review
  • GitHub Check: test (3.11)
  • GitHub Check: test (3.13)
  • GitHub Check: test (3.12)
  • GitHub Check: type-check (3.12)
  • GitHub Check: type-check (3.13)
  • GitHub Check: type-check (3.11)
  • GitHub Check: lint
  • GitHub Check: end-to-end tests
  • GitHub Check: Analyze (typescript)
  • GitHub Check: types
  • GitHub Check: Analyze (python)
  • GitHub Check: lint
  • GitHub Check: check-docs-sync
  • GitHub Check: Check PR Status
🧰 Additional context used
📓 Path-based instructions (3)
autogpt_platform/backend/**/*.py

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

autogpt_platform/backend/**/*.py: Use Python 3.11 (required; managed by Poetry via pyproject.toml) for backend development
Always run 'poetry run format' (Black + isort) before linting in backend development
Always run 'poetry run lint' (ruff) after formatting in backend development

autogpt_platform/backend/**/*.py: Use poetry run ... command for executing Python package dependencies
Use top-level imports only — avoid local/inner imports except for lazy imports of heavy optional dependencies like openpyxl
Use absolute imports with from backend.module import ... for cross-package imports; single-dot relative imports are acceptable for sibling modules within the same package; avoid double-dot relative imports
Do not use duck typing — avoid hasattr/getattr/isinstance for type dispatch; use typed interfaces/unions/protocols instead
Use Pydantic models over dataclass/namedtuple/dict for structured data
Do not use linter suppressors — no # type: ignore, # noqa, # pyright: ignore; fix the type/code instead
Prefer list comprehensions over manual loop-and-append patterns
Use early return with guard clauses first to avoid deep nesting
Use %s for deferred interpolation in debug log statements for efficiency; use f-strings elsewhere for readability (e.g., logger.debug("Processing %s items", count) vs logger.info(f"Processing {count} items"))
Sanitize error paths by using os.path.basename() in error messages to avoid leaking directory structure
Be aware of TOCTOU (Time-Of-Check-Time-Of-Use) issues — avoid check-then-act patterns for file access and credit charging
Use transaction=True for Redis pipelines to ensure atomicity on multi-step operations
Use max(0, value) guards for computed values that should never be negative
Keep files under ~300 lines; if a file grows beyond this, split by responsibility (extract helpers, models, or a sub-module into a new file)
Keep functions under ~40 lines; extract named helpers when a function grows longer
...

Files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
autogpt_platform/backend/backend/blocks/**/*.py

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

autogpt_platform/backend/backend/blocks/**/*.py: Inherit from 'Block' base class with input/output schemas when adding new blocks in backend
Implement 'run' method with proper error handling in backend blocks
Generate block UUID using 'uuid.uuid4()' when creating new blocks in backend
Write tests alongside block implementation when adding new blocks in backend

autogpt_platform/backend/backend/blocks/**/*.py: For blocks handling files, use store_media_file() with return_format="for_local_processing" when processing with local tools (ffmpeg, MoviePy, PIL)
For blocks handling files, use store_media_file() with return_format="for_external_api" when sending content to external APIs (Replicate, OpenAI)
For blocks returning files, use store_media_file() with return_format="for_block_output" to enable auto-adaptation to execution context (workspace:// in CoPilot, data URI in graphs)
When creating new blocks, inherit from Block base class, define input/output schemas using BlockSchema, implement async run method, and generate unique block ID using uuid.uuid4()

Files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
autogpt_platform/{backend,autogpt_libs}/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

Format Python code with poetry run format

Files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
🧠 Learnings (16)
📚 Learning: 2026-02-05T04:11:00.596Z
Learnt from: ntindle
Repo: Significant-Gravitas/AutoGPT PR: 11796
File: autogpt_platform/backend/backend/blocks/video/concat.py:3-4
Timestamp: 2026-02-05T04:11:00.596Z
Learning: In autogpt_platform/backend/backend/blocks/**/*.py, when creating a new block, generate a UUID once with uuid.uuid4() and hard-code the resulting string as the block's id parameter. Do not call uuid.uuid4() at runtime; IDs must be constant across all imports and runs to ensure stability.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:32:21.686Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 12417
File: autogpt_platform/backend/backend/blocks/agent_mail/pods.py:62-74
Timestamp: 2026-03-16T16:32:21.686Z
Learning: In autogpt_platform/backend/backend/blocks/, the Block base class execute() already wraps run() in a try/except to convert uncaught exceptions into BlockExecutionError/BlockUnknownError. Do not add per-block try/except in individual block run() methods, as this is not the established pattern (e.g., Gmail, Slack, Todoist blocks omit it). Only use explicit try/except within blocks that need to distinguish between success and error yield paths inside a generator (e.g., attachment blocks). This guidance applies to all Python files under autogpt_platform/backend/backend/blocks/ and similar block implementations; avoid duplicating error handling in run() unless a block requires generator-based branching.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-04-23T12:55:26.122Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12893
File: autogpt_platform/backend/backend/blocks/ayrshare/post_to_tiktok.py:24-24
Timestamp: 2026-04-23T12:55:26.122Z
Learning: Cost billing via the cost(*costs) decorator is applied at input-evaluation time (before a block’s run() executes). Therefore, mutating input_data inside run() will not change billing. When a block’s billing depends on a field plus URL/sniff-derived signals, treat the explicitly declared billing field (e.g., is_video) as the only billing source—set it correctly before run() (or in the code path that occurs before the decorator evaluates input_data). This should be checked for all blocks under autogpt_platform/backend/backend/blocks/ so billing signals are not mistakenly assumed to update during run().

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-02-26T17:02:22.448Z
Learnt from: Pwuts
Repo: Significant-Gravitas/AutoGPT PR: 12211
File: .pre-commit-config.yaml:160-179
Timestamp: 2026-02-26T17:02:22.448Z
Learning: Keep the pre-commit hook pattern broad for autogpt_platform/backend to ensure OpenAPI schema changes are captured. Do not narrow to backend/api/ alone, since the generated schema depends on Pydantic models across multiple directories (backend/data/, backend/blocks/, backend/copilot/, backend/integrations/, backend/util/). Narrowing could miss schema changes and cause frontend type desynchronization.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-05T15:42:08.207Z
Learnt from: ntindle
Repo: Significant-Gravitas/AutoGPT PR: 12297
File: .claude/skills/backend-check/SKILL.md:14-16
Timestamp: 2026-03-05T15:42:08.207Z
Learning: In Python files under autogpt_platform/backend (recursively), rely on poetry run format to perform formatting (Black + isort) and linting (ruff). Do not run poetry run lint as a separate step after poetry run format, since format already includes linting checks.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:30:11.452Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 12417
File: autogpt_platform/backend/backend/blocks/agent_mail/threads.py:80-102
Timestamp: 2026-03-16T16:30:11.452Z
Learning: In autogpt_platform/backend/backend/blocks/ (and related blocks under autogpt_platform/backend/backend/blocks/), do not add try/except blocks around a block's run() method for standard error propagation. The block executor framework (backend/executor/manager.py) catches uncaught exceptions from run() and emits them on the 'error' output. Only add explicit try/except blocks when you need to control partial outputs in failure cases (e.g., certain outputs must not be yielded on error, as in attachment blocks). This is the standard pattern across the codebase; apply it broadly to blocks' run() implementations.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:30:23.196Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 12417
File: autogpt_platform/backend/backend/blocks/agent_mail/pods.py:62-74
Timestamp: 2026-03-16T16:30:23.196Z
Learning: In any Python file under autogpt_platform/backend/backend/blocks, do not add a try/except around run() solely for standard error handling. The block framework’s _execute() in _base.py already catches unhandled exceptions and re-raises as BlockExecutionError or BlockUnknownError. If you yield ("error", message), _execute() raises BlockExecutionError immediately, so the error port will not propagate downstream. Reserve explicit try/except for scenarios where you must control partial output (e.g., attachment blocks that must skip yielding content_base64 on failure).

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:30:11.452Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 12417
File: autogpt_platform/backend/backend/blocks/agent_mail/threads.py:80-102
Timestamp: 2026-03-16T16:30:11.452Z
Learning: Do not wrap synchronous AgentMail SDK calls with asyncio.to_thread() in blocks under autogpt_platform/backend/backend/blocks (and across the codebase). The block executor runs node execution in dedicated threads via asyncio.run_coroutine_threadsafe (see manager.py around lines ~745-752 and ~1079). The existing pattern avoids using asyncio.to_thread for SDK calls inside async run() methods, so maintain that approach and do not add to_thread usage in these code paths.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:35:40.236Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12440
File: autogpt_platform/backend/backend/api/features/workflow_import.py:54-63
Timestamp: 2026-03-16T16:35:40.236Z
Learning: Avoid using the word 'competitor' in public-facing identifiers and text. Use neutral naming for API paths, model names, function names, and UI text. Examples: rename 'CompetitorFormat' to 'SourcePlatform', 'convert_competitor_workflow' to 'convert_workflow', '/competitor-workflow' to '/workflow'. Apply this guideline to files under autogpt_platform/backend and autogpt_platform/frontend.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-31T15:37:38.626Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12623
File: autogpt_platform/backend/backend/copilot/tools/agent_generator/fixer.py:37-47
Timestamp: 2026-03-31T15:37:38.626Z
Learning: When validating/constructing Anthropic API model IDs in Significant-Gravitas/AutoGPT, allow the hyphen-separated Claude Opus 4.6 model ID `claude-opus-4-6` (it corresponds to `LlmModel.CLAUDE_4_6_OPUS` in `autogpt_platform/backend/backend/blocks/llm.py`). Do NOT require the dot-separated form in Anthropic contexts. Only OpenRouter routing variants should use the dot separator (e.g., `anthropic/claude-opus-4.6`); `claude-opus-4-6` should be treated as correct when passed to Anthropic, and flagged only if it’s used in the OpenRouter path where the dot form is expected.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-04-15T02:43:36.890Z
Learnt from: ntindle
Repo: Significant-Gravitas/AutoGPT PR: 12780
File: autogpt_platform/backend/backend/copilot/tools/workspace_files.py:0-0
Timestamp: 2026-04-15T02:43:36.890Z
Learning: When reviewing Python exception handlers, do not flag `isinstance(e, X)` checks as dead/unreachable if the caught exception `X` is a subclass of the exception type being handled. For example, if `X` (e.g., `VirusScanError`) inherits from `ValueError` (directly or via an intermediate class) and it can be raised within an `except ValueError:` block, then `isinstance(e, X)` inside that handler is reachable and should not be treated as dead code.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-05-23T05:29:43.085Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 13200
File: autogpt_platform/backend/backend/executor/scheduler.py:590-593
Timestamp: 2026-05-23T05:29:43.085Z
Learning: When reviewing Python code that uses Pydantic discriminated/tagged unions (e.g., `Annotated[Union[...], Field(discriminator="kind")]`), recognize that using `isinstance(x, SomeVariantInfo)` to narrow the union is an intentional and correct runtime guard and should also enable static type narrowing in tools like Pyright. Do not recommend replacing such `isinstance`-based narrowing with `cast(...)` when the check already proves the variant at runtime.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-04-22T11:46:04.431Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12881
File: autogpt_platform/backend/backend/copilot/config.py:0-0
Timestamp: 2026-04-22T11:46:04.431Z
Learning: Do not flag the Claude Sonnet 4.6 model ID as incorrect when it uses the project’s established hyphenated convention: `anthropic/claude-sonnet-4-6`. This hyphen form is the intentional, production convention and should be treated as valid (including in files like llm.py, blocks tests, reasoning.py, `_is_anthropic_model` tests, and config defaults). Note that OpenRouter also accepts the dot variant `anthropic/claude-sonnet-4.6`, so either form may be tolerated, but `anthropic/claude-sonnet-4-6` should be considered the standard to match project usage.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-04-22T11:46:12.892Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12881
File: autogpt_platform/backend/backend/copilot/baseline/service.py:322-332
Timestamp: 2026-04-22T11:46:12.892Z
Learning: In this codebase (Significant-Gravitas/AutoGPT), OpenRouter-routed Anthropic model IDs should use the hyphen-separated convention (e.g., `anthropic/claude-sonnet-4-6`, `anthropic/claude-opus-4-6`). Although OpenRouter may accept both hyphen and dot variants, treat the hyphen-separated form as the intended, correct codebase-wide convention and do not flag it as an error. Only flag the dot-separated variant (e.g., `anthropic/claude-sonnet-4.6`) as incorrect when reviewing/validating model ID strings for OpenRouter-routed Anthropic models.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-05-07T18:48:14.242Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 13040
File: autogpt_platform/backend/backend/blocks/llm.py:0-0
Timestamp: 2026-05-07T18:48:14.242Z
Learning: In this repository, isort may split imports from the same module into separate blocks when some imports are aliased (e.g., `from module import X as Y`) and others are not. Preserve the two-block layout when it results from isort (such as keeping `from openai.types.chat import ChatCompletion as OpenAIChatCompletion` separate from non-aliased imports from `openai.types.chat`). Do not treat that split as a style issue during review; merging them into a single block can fail CI with `Imports are incorrectly sorted and/or formatted`.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-05-26T14:24:34.866Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 13217
File: autogpt_platform/backend/backend/api/features/search/service.py:137-137
Timestamp: 2026-05-26T14:24:34.866Z
Learning: In the Significant-Gravitas/AutoGPT backend, treat `user_id` (an opaque UUID used only for correlation/tracing) as non-PII. Do not flag direct logging of `user_id` in `logger.warning`/`logger.info` statements as a PII exposure issue, as the established convention is to log `user_id` for tracing while reserving PII for fields like email or display name.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
🔇 Additional comments (6)
autogpt_platform/backend/backend/blocks/github/pull_requests.py (6)

146-185: Note: Only first 100 PRs are returned due to pagination limit.

The API call uses per_page=100 without handling pagination. Repositories with more than 100 matching PRs will only receive the first page. This is acceptable if it's the intended behavior, but consider documenting this limitation or implementing pagination for larger repositories.


35-46: LGTM!


52-68: LGTM!


81-143: LGTM!


187-202: LGTM!


620-632: LGTM!

Comment thread autogpt_platform/backend/backend/blocks/github/pull_requests.py Outdated
Comment on lines +39 to +46
since: str = SchemaField(
description=(
"Only return pull requests created/updated at or after this time. "
"ISO 8601 format: YYYY-MM-DDTHH:MM:SSZ. Leave empty for no filter."
),
default="",
advanced=True,
)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Documentation/implementation mismatch: since filter only checks created_at

The description at line 41 states "created/updated at or after" but the implementation at lines 164-168 only filters based on created_at. PRs updated after since but created before it will be excluded.

Either update the description to match the behavior, or extend the filter to also check updated_at.

Option A: Fix the description to match implementation
         since: str = SchemaField(
             description=(
-                "Only return pull requests created/updated at or after this time. "
+                "Only return pull requests created at or after this time. "
                 "ISO 8601 format: YYYY-MM-DDTHH:MM:SSZ. Leave empty for no filter."
             ),
             default="",
             advanced=True,
         )
Option B: Extend filter to also check `updated_at`
         for pr in data:
             created_at = pr.get("created_at", "")
+            updated_at = pr.get("updated_at", "")
             if since_dt and created_at:
                 pr_dt = datetime.fromisoformat(created_at.replace("Z", "+00:00"))
-                if pr_dt < since_dt:
+                updated_dt = (
+                    datetime.fromisoformat(updated_at.replace("Z", "+00:00"))
+                    if updated_at
+                    else pr_dt
+                )
+                if pr_dt < since_dt and updated_dt < since_dt:
                     continue

Also applies to: 163-168

🤖 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 `@autogpt_platform/backend/backend/blocks/github/pull_requests.py` around lines
39 - 46, The docs say the SchemaField since should filter PRs "created/updated
at or after" but the current filter only checks created_at; modify the filter
logic that currently compares created_at (the block around the code checking
created_at >= since) to instead include PRs where either created_at >= since OR
updated_at >= since (parse/compare both ISO timestamps robustly and handle
empty/default since value), or alternatively change the since SchemaField
description to only mention creation; prefer updating the filter so both
created_at and updated_at are considered (refer to the since SchemaField and the
function/block that currently filters on created_at).

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (1)
autogpt_platform/backend/backend/blocks/github/pull_requests.py (1)

279-295: 💤 Low value

Consider dropping the try/except wrapper around run().

The block executor already converts uncaught exceptions from run() into the error output, so this manual wrapper is generally redundant; it's only warranted when you must control partial yields on failure. Note the rest of this file (MakePR/Assign/Merge) does use this pattern, so confirm which convention you want to keep here.

Based on learnings: "do not add try/except blocks around a block's run() method for standard error propagation... The block executor framework catches uncaught exceptions from run() and emits them on the 'error' output."

🤖 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 `@autogpt_platform/backend/backend/blocks/github/pull_requests.py` around lines
279 - 295, Remove the redundant try/except around the run() logic: call
self.list_prs(...) directly, yield "pull_requests" and then each "pull_request"
from the result, and let uncaught exceptions propagate so the block executor can
emit the "error" output; locate the block's run method (the function containing
the current try/except), remove the try/except wrapper, keep the calls to
list_prs and the yields ("pull_requests" and "pull_request") unchanged, and
ensure this aligns with the pattern used by MakePR/Assign/Merge.
🤖 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 `@autogpt_platform/backend/backend/blocks/github/pull_requests.py`:
- Line 262: The code assumes pr.get("user")/pr.get("base")/pr.get("head") return
dicts and calls .get(...) on them, which raises AttributeError when GitHub
returns null; update the mappings that set "author" and the base/head fields to
use a safe fallback like (pr.get("user") or {}).get("login","") and similarly
(pr.get("base") or {}).get("ref","") and (pr.get("head") or {}).get("ref","") so
the code handles null user/base/head without crashing (look for the mapping that
sets "author" and the base/head extraction in pull_requests.py).
- Around line 254-256: The current check uses fragile lexicographic string
comparison between created_at and since; instead parse both created_at (from
pr.get("created_at")) and the user-supplied since into timezone-aware datetime
objects (e.g., using a robust ISO parser like dateutil.parser.isoparse or
normalizing 'Z' to '+00:00' and using datetime.fromisoformat), handle parse
errors gracefully (fall back to skipping the filter or logging), then perform a
proper datetime comparison (created_at_dt < since_dt) before returning None;
update the block around the created_at and since variables to perform this
parsing and comparison.

---

Nitpick comments:
In `@autogpt_platform/backend/backend/blocks/github/pull_requests.py`:
- Around line 279-295: Remove the redundant try/except around the run() logic:
call self.list_prs(...) directly, yield "pull_requests" and then each
"pull_request" from the result, and let uncaught exceptions propagate so the
block executor can emit the "error" output; locate the block's run method (the
function containing the current try/except), remove the try/except wrapper, keep
the calls to list_prs and the yields ("pull_requests" and "pull_request")
unchanged, and ensure this aligns with the pattern used by MakePR/Assign/Merge.
🪄 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

Run ID: ffa9030e-e03d-4185-b566-3dc84711c8f2

📥 Commits

Reviewing files that changed from the base of the PR and between 7e1fec7 and 9a29da3.

📒 Files selected for processing (1)
  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📜 Review details
⏰ 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). (13)
  • GitHub Check: end-to-end tests
  • GitHub Check: type-check (3.11)
  • GitHub Check: test (3.13)
  • GitHub Check: test (3.11)
  • GitHub Check: type-check (3.13)
  • GitHub Check: test (3.12)
  • GitHub Check: type-check (3.12)
  • GitHub Check: lint
  • GitHub Check: check-docs-sync
  • GitHub Check: Analyze (typescript)
  • GitHub Check: Analyze (python)
  • GitHub Check: Check PR Status
  • GitHub Check: Seer Code Review
🧰 Additional context used
📓 Path-based instructions (3)
autogpt_platform/backend/**/*.py

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

autogpt_platform/backend/**/*.py: Use Python 3.11 (required; managed by Poetry via pyproject.toml) for backend development
Always run 'poetry run format' (Black + isort) before linting in backend development
Always run 'poetry run lint' (ruff) after formatting in backend development

autogpt_platform/backend/**/*.py: Use poetry run ... command for executing Python package dependencies
Use top-level imports only — avoid local/inner imports except for lazy imports of heavy optional dependencies like openpyxl
Use absolute imports with from backend.module import ... for cross-package imports; single-dot relative imports are acceptable for sibling modules within the same package; avoid double-dot relative imports
Do not use duck typing — avoid hasattr/getattr/isinstance for type dispatch; use typed interfaces/unions/protocols instead
Use Pydantic models over dataclass/namedtuple/dict for structured data
Do not use linter suppressors — no # type: ignore, # noqa, # pyright: ignore; fix the type/code instead
Prefer list comprehensions over manual loop-and-append patterns
Use early return with guard clauses first to avoid deep nesting
Use %s for deferred interpolation in debug log statements for efficiency; use f-strings elsewhere for readability (e.g., logger.debug("Processing %s items", count) vs logger.info(f"Processing {count} items"))
Sanitize error paths by using os.path.basename() in error messages to avoid leaking directory structure
Be aware of TOCTOU (Time-Of-Check-Time-Of-Use) issues — avoid check-then-act patterns for file access and credit charging
Use transaction=True for Redis pipelines to ensure atomicity on multi-step operations
Use max(0, value) guards for computed values that should never be negative
Keep files under ~300 lines; if a file grows beyond this, split by responsibility (extract helpers, models, or a sub-module into a new file)
Keep functions under ~40 lines; extract named helpers when a function grows longer
...

Files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
autogpt_platform/backend/backend/blocks/**/*.py

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

autogpt_platform/backend/backend/blocks/**/*.py: Inherit from 'Block' base class with input/output schemas when adding new blocks in backend
Implement 'run' method with proper error handling in backend blocks
Generate block UUID using 'uuid.uuid4()' when creating new blocks in backend
Write tests alongside block implementation when adding new blocks in backend

autogpt_platform/backend/backend/blocks/**/*.py: For blocks handling files, use store_media_file() with return_format="for_local_processing" when processing with local tools (ffmpeg, MoviePy, PIL)
For blocks handling files, use store_media_file() with return_format="for_external_api" when sending content to external APIs (Replicate, OpenAI)
For blocks returning files, use store_media_file() with return_format="for_block_output" to enable auto-adaptation to execution context (workspace:// in CoPilot, data URI in graphs)
When creating new blocks, inherit from Block base class, define input/output schemas using BlockSchema, implement async run method, and generate unique block ID using uuid.uuid4()

Files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
autogpt_platform/{backend,autogpt_libs}/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

Format Python code with poetry run format

Files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
🧠 Learnings (16)
📚 Learning: 2026-02-05T04:11:00.596Z
Learnt from: ntindle
Repo: Significant-Gravitas/AutoGPT PR: 11796
File: autogpt_platform/backend/backend/blocks/video/concat.py:3-4
Timestamp: 2026-02-05T04:11:00.596Z
Learning: In autogpt_platform/backend/backend/blocks/**/*.py, when creating a new block, generate a UUID once with uuid.uuid4() and hard-code the resulting string as the block's id parameter. Do not call uuid.uuid4() at runtime; IDs must be constant across all imports and runs to ensure stability.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:32:21.686Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 12417
File: autogpt_platform/backend/backend/blocks/agent_mail/pods.py:62-74
Timestamp: 2026-03-16T16:32:21.686Z
Learning: In autogpt_platform/backend/backend/blocks/, the Block base class execute() already wraps run() in a try/except to convert uncaught exceptions into BlockExecutionError/BlockUnknownError. Do not add per-block try/except in individual block run() methods, as this is not the established pattern (e.g., Gmail, Slack, Todoist blocks omit it). Only use explicit try/except within blocks that need to distinguish between success and error yield paths inside a generator (e.g., attachment blocks). This guidance applies to all Python files under autogpt_platform/backend/backend/blocks/ and similar block implementations; avoid duplicating error handling in run() unless a block requires generator-based branching.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-04-23T12:55:26.122Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12893
File: autogpt_platform/backend/backend/blocks/ayrshare/post_to_tiktok.py:24-24
Timestamp: 2026-04-23T12:55:26.122Z
Learning: Cost billing via the cost(*costs) decorator is applied at input-evaluation time (before a block’s run() executes). Therefore, mutating input_data inside run() will not change billing. When a block’s billing depends on a field plus URL/sniff-derived signals, treat the explicitly declared billing field (e.g., is_video) as the only billing source—set it correctly before run() (or in the code path that occurs before the decorator evaluates input_data). This should be checked for all blocks under autogpt_platform/backend/backend/blocks/ so billing signals are not mistakenly assumed to update during run().

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-02-26T17:02:22.448Z
Learnt from: Pwuts
Repo: Significant-Gravitas/AutoGPT PR: 12211
File: .pre-commit-config.yaml:160-179
Timestamp: 2026-02-26T17:02:22.448Z
Learning: Keep the pre-commit hook pattern broad for autogpt_platform/backend to ensure OpenAPI schema changes are captured. Do not narrow to backend/api/ alone, since the generated schema depends on Pydantic models across multiple directories (backend/data/, backend/blocks/, backend/copilot/, backend/integrations/, backend/util/). Narrowing could miss schema changes and cause frontend type desynchronization.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-05T15:42:08.207Z
Learnt from: ntindle
Repo: Significant-Gravitas/AutoGPT PR: 12297
File: .claude/skills/backend-check/SKILL.md:14-16
Timestamp: 2026-03-05T15:42:08.207Z
Learning: In Python files under autogpt_platform/backend (recursively), rely on poetry run format to perform formatting (Black + isort) and linting (ruff). Do not run poetry run lint as a separate step after poetry run format, since format already includes linting checks.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:30:11.452Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 12417
File: autogpt_platform/backend/backend/blocks/agent_mail/threads.py:80-102
Timestamp: 2026-03-16T16:30:11.452Z
Learning: In autogpt_platform/backend/backend/blocks/ (and related blocks under autogpt_platform/backend/backend/blocks/), do not add try/except blocks around a block's run() method for standard error propagation. The block executor framework (backend/executor/manager.py) catches uncaught exceptions from run() and emits them on the 'error' output. Only add explicit try/except blocks when you need to control partial outputs in failure cases (e.g., certain outputs must not be yielded on error, as in attachment blocks). This is the standard pattern across the codebase; apply it broadly to blocks' run() implementations.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:30:23.196Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 12417
File: autogpt_platform/backend/backend/blocks/agent_mail/pods.py:62-74
Timestamp: 2026-03-16T16:30:23.196Z
Learning: In any Python file under autogpt_platform/backend/backend/blocks, do not add a try/except around run() solely for standard error handling. The block framework’s _execute() in _base.py already catches unhandled exceptions and re-raises as BlockExecutionError or BlockUnknownError. If you yield ("error", message), _execute() raises BlockExecutionError immediately, so the error port will not propagate downstream. Reserve explicit try/except for scenarios where you must control partial output (e.g., attachment blocks that must skip yielding content_base64 on failure).

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:30:11.452Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 12417
File: autogpt_platform/backend/backend/blocks/agent_mail/threads.py:80-102
Timestamp: 2026-03-16T16:30:11.452Z
Learning: Do not wrap synchronous AgentMail SDK calls with asyncio.to_thread() in blocks under autogpt_platform/backend/backend/blocks (and across the codebase). The block executor runs node execution in dedicated threads via asyncio.run_coroutine_threadsafe (see manager.py around lines ~745-752 and ~1079). The existing pattern avoids using asyncio.to_thread for SDK calls inside async run() methods, so maintain that approach and do not add to_thread usage in these code paths.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-16T16:35:40.236Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12440
File: autogpt_platform/backend/backend/api/features/workflow_import.py:54-63
Timestamp: 2026-03-16T16:35:40.236Z
Learning: Avoid using the word 'competitor' in public-facing identifiers and text. Use neutral naming for API paths, model names, function names, and UI text. Examples: rename 'CompetitorFormat' to 'SourcePlatform', 'convert_competitor_workflow' to 'convert_workflow', '/competitor-workflow' to '/workflow'. Apply this guideline to files under autogpt_platform/backend and autogpt_platform/frontend.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-03-31T15:37:38.626Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12623
File: autogpt_platform/backend/backend/copilot/tools/agent_generator/fixer.py:37-47
Timestamp: 2026-03-31T15:37:38.626Z
Learning: When validating/constructing Anthropic API model IDs in Significant-Gravitas/AutoGPT, allow the hyphen-separated Claude Opus 4.6 model ID `claude-opus-4-6` (it corresponds to `LlmModel.CLAUDE_4_6_OPUS` in `autogpt_platform/backend/backend/blocks/llm.py`). Do NOT require the dot-separated form in Anthropic contexts. Only OpenRouter routing variants should use the dot separator (e.g., `anthropic/claude-opus-4.6`); `claude-opus-4-6` should be treated as correct when passed to Anthropic, and flagged only if it’s used in the OpenRouter path where the dot form is expected.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-04-15T02:43:36.890Z
Learnt from: ntindle
Repo: Significant-Gravitas/AutoGPT PR: 12780
File: autogpt_platform/backend/backend/copilot/tools/workspace_files.py:0-0
Timestamp: 2026-04-15T02:43:36.890Z
Learning: When reviewing Python exception handlers, do not flag `isinstance(e, X)` checks as dead/unreachable if the caught exception `X` is a subclass of the exception type being handled. For example, if `X` (e.g., `VirusScanError`) inherits from `ValueError` (directly or via an intermediate class) and it can be raised within an `except ValueError:` block, then `isinstance(e, X)` inside that handler is reachable and should not be treated as dead code.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-05-23T05:29:43.085Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 13200
File: autogpt_platform/backend/backend/executor/scheduler.py:590-593
Timestamp: 2026-05-23T05:29:43.085Z
Learning: When reviewing Python code that uses Pydantic discriminated/tagged unions (e.g., `Annotated[Union[...], Field(discriminator="kind")]`), recognize that using `isinstance(x, SomeVariantInfo)` to narrow the union is an intentional and correct runtime guard and should also enable static type narrowing in tools like Pyright. Do not recommend replacing such `isinstance`-based narrowing with `cast(...)` when the check already proves the variant at runtime.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-04-22T11:46:04.431Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12881
File: autogpt_platform/backend/backend/copilot/config.py:0-0
Timestamp: 2026-04-22T11:46:04.431Z
Learning: Do not flag the Claude Sonnet 4.6 model ID as incorrect when it uses the project’s established hyphenated convention: `anthropic/claude-sonnet-4-6`. This hyphen form is the intentional, production convention and should be treated as valid (including in files like llm.py, blocks tests, reasoning.py, `_is_anthropic_model` tests, and config defaults). Note that OpenRouter also accepts the dot variant `anthropic/claude-sonnet-4.6`, so either form may be tolerated, but `anthropic/claude-sonnet-4-6` should be considered the standard to match project usage.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-04-22T11:46:12.892Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 12881
File: autogpt_platform/backend/backend/copilot/baseline/service.py:322-332
Timestamp: 2026-04-22T11:46:12.892Z
Learning: In this codebase (Significant-Gravitas/AutoGPT), OpenRouter-routed Anthropic model IDs should use the hyphen-separated convention (e.g., `anthropic/claude-sonnet-4-6`, `anthropic/claude-opus-4-6`). Although OpenRouter may accept both hyphen and dot variants, treat the hyphen-separated form as the intended, correct codebase-wide convention and do not flag it as an error. Only flag the dot-separated variant (e.g., `anthropic/claude-sonnet-4.6`) as incorrect when reviewing/validating model ID strings for OpenRouter-routed Anthropic models.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-05-07T18:48:14.242Z
Learnt from: majdyz
Repo: Significant-Gravitas/AutoGPT PR: 13040
File: autogpt_platform/backend/backend/blocks/llm.py:0-0
Timestamp: 2026-05-07T18:48:14.242Z
Learning: In this repository, isort may split imports from the same module into separate blocks when some imports are aliased (e.g., `from module import X as Y`) and others are not. Preserve the two-block layout when it results from isort (such as keeping `from openai.types.chat import ChatCompletion as OpenAIChatCompletion` separate from non-aliased imports from `openai.types.chat`). Do not treat that split as a style issue during review; merging them into a single block can fail CI with `Imports are incorrectly sorted and/or formatted`.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
📚 Learning: 2026-05-26T14:24:34.866Z
Learnt from: Abhi1992002
Repo: Significant-Gravitas/AutoGPT PR: 13217
File: autogpt_platform/backend/backend/api/features/search/service.py:137-137
Timestamp: 2026-05-26T14:24:34.866Z
Learning: In the Significant-Gravitas/AutoGPT backend, treat `user_id` (an opaque UUID used only for correlation/tracing) as non-PII. Do not flag direct logging of `user_id` in `logger.warning`/`logger.info` statements as a PII exposure issue, as the established convention is to log `user_id` for tracing while reserving PII for fields like email or display name.

Applied to files:

  • autogpt_platform/backend/backend/blocks/github/pull_requests.py
🔇 Additional comments (4)
autogpt_platform/backend/backend/blocks/github/pull_requests.py (4)

67-74: ⚡ Quick win

Description still says "created/updated" but only created_at is filtered (Line 255). Align the wording with the implementation or extend the filter to consider updated_at.


38-82: LGTM!

Also applies to: 84-108


113-190: LGTM!


712-715: LGTM!

Comment on lines +254 to +256
created_at = pr.get("created_at", "")
if since and created_at and created_at < since:
return None
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

since filter relies on fragile lexicographic string comparison.

GitHub returns created_at in canonical ...Z form, but the user-supplied since may use an offset (+00:00) or a date-only value. Lexicographic comparison then silently filters incorrectly (e.g. "...Z" vs "...+00:00" differ at the offset char). Parse both to datetime for a correct, timezone-aware comparison.

♻️ Proposed fix
+from datetime import datetime
@@
-        created_at = pr.get("created_at", "")
-        if since and created_at and created_at < since:
-            return None
+        created_at = pr.get("created_at", "")
+        if since and created_at:
+            since_dt = datetime.fromisoformat(since.replace("Z", "+00:00"))
+            created_dt = datetime.fromisoformat(created_at.replace("Z", "+00:00"))
+            if created_dt < since_dt:
+                return None
🤖 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 `@autogpt_platform/backend/backend/blocks/github/pull_requests.py` around lines
254 - 256, The current check uses fragile lexicographic string comparison
between created_at and since; instead parse both created_at (from
pr.get("created_at")) and the user-supplied since into timezone-aware datetime
objects (e.g., using a robust ISO parser like dateutil.parser.isoparse or
normalizing 'Z' to '+00:00' and using datetime.fromisoformat), handle parse
errors gracefully (fall back to skipping the filter or logging), then perform a
proper datetime comparison (created_at_dt < since_dt) before returning None;
update the block around the created_at and since variables to perform this
parsing and comparison.

"url": pr.get("html_url", ""),
"number": pr.get("number", 0),
"state": pr.get("state", ""),
"author": pr.get("user", {}).get("login", ""),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Guard against null PR author to avoid AttributeError.

GitHub can return "user": null for PRs from deleted/ghost accounts. Since the key is present, pr.get("user", {}) returns None (not the default), so .get("login", "") raises AttributeError and fails the whole block.

🛡️ Proposed fix
-            "author": pr.get("user", {}).get("login", ""),
+            "author": (pr.get("user") or {}).get("login", ""),
The same pattern applies to `base`/`head` (Line 266-267), though those are far less likely to be null.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
"author": pr.get("user", {}).get("login", ""),
"author": (pr.get("user") or {}).get("login", ""),
🤖 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 `@autogpt_platform/backend/backend/blocks/github/pull_requests.py` at line 262,
The code assumes pr.get("user")/pr.get("base")/pr.get("head") return dicts and
calls .get(...) on them, which raises AttributeError when GitHub returns null;
update the mappings that set "author" and the base/head fields to use a safe
fallback like (pr.get("user") or {}).get("login","") and similarly
(pr.get("base") or {}).get("ref","") and (pr.get("head") or {}).get("ref","") so
the code handles null user/base/head without crashing (look for the mapping that
sets "author" and the base/head extraction in pull_requests.py).

Comment on lines +254 to +256
created_at = pr.get("created_at", "")
if since and created_at and created_at < since:
return None
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The since filter for pull requests only checks created_at, ignoring updated_at. This leads to incorrect results when sorting by updated.
Severity: MEDIUM

Suggested Fix

Modify _parse_pr to honor the since filter based on the sort parameter. If sort is "updated", filter using updated_at. Otherwise, filter using created_at. This aligns the implementation with the documented behavior of filtering by "created/updated" time.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: autogpt_platform/backend/backend/blocks/github/pull_requests.py#L254-L256

Potential issue: The `since` input field's description states it filters pull requests
"created/updated at or after this time." However, the implementation in `_parse_pr` only
compares the `since` value against the `created_at` timestamp. The `updated_at` field is
never evaluated for filtering. Consequently, when a user combines `sort="updated"` with
a `since` value, the filter behaves unexpectedly, applying to the creation date instead
of the update date, leading to incorrect and confusing results.

@codecov
Copy link
Copy Markdown

codecov Bot commented May 31, 2026

Codecov Report

❌ Patch coverage is 41.66667% with 35 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.73%. Comparing base (ab3221a) to head (bc62929).
⚠️ Report is 273 commits behind head on dev.

❌ Your patch check has failed because the patch coverage (41.66%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files
@@            Coverage Diff             @@
##              dev   #13253      +/-   ##
==========================================
+ Coverage   65.04%   69.73%   +4.69%     
==========================================
  Files        1830     2201     +371     
  Lines      135503   172549   +37046     
  Branches    14516    17257    +2741     
==========================================
+ Hits        88142   120334   +32192     
- Misses      44651    48869    +4218     
- Partials     2710     3346     +636     
Flag Coverage Δ
platform-backend 80.39% <41.66%> (+4.68%) ⬆️
platform-frontend-e2e 30.81% <ø> (-0.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
Platform Backend 80.39% <41.66%> (+4.68%) ⬆️
Platform Frontend 26.42% <ø> (-1.09%) ⬇️
AutoGPT Libs ∅ <ø> (∅)
Classic AutoGPT 28.43% <ø> (ø)
🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@Abhi1992002 Abhi1992002 marked this pull request as draft May 31, 2026 05:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: 🆕 Needs initial review

Development

Successfully merging this pull request may close these issues.

1 participant