feat: add WIP limit of 5 for research in review tickets #814
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add configurable RESEARCH_WIP_LIMIT environment variable (set to 5) - Check current tickets in 'research in review' status before fetching new work - Calculate available capacity and only fetch tickets up to that limit - Prevent new work when at or above WIP limit - Add error handling for Linear API failures - Validate jq output to ensure proper number parsing - Add GitHub Actions notice and warning annotations for monitoring - Show warnings when approaching or at WIP limit - Default to safe state (no capacity) on errors This creates a simple kanban pull system ensuring that at most 5 tickets are in the 'research in review' status at any given time, preventing bottlenecks in the review process.
Contributor
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to 2bf5c68 in 2 minutes and 52 seconds. Click for details.
- Reviewed
95lines of code in1files - Skipped
0files when reviewing. - Skipped posting
5draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. .github/workflows/linear-research-tickets.yml:63
- Draft comment:
Consider assigning the RESEARCH_WIP_LIMIT value to a bash variable (e.g. wip_limit) before doing arithmetic. This avoids inline templating within arithmetic expansion and clarifies the intent. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The current code works fine - GitHub Actions environment variables can be used directly in bash arithmetic. While assigning to a variable first might be slightly clearer, it's not a significant improvement that warrants a code change. The current code is perfectly readable and follows common GitHub Actions patterns. The suggestion is more about style than substance. The comment does have a point about readability - having a local variable would make the code slightly more maintainable. And it would avoid potential issues with special characters in the environment variable. However, this is a very minor style preference in a GitHub Actions workflow file. The current code is clear enough and follows typical patterns. The benefit doesn't justify the churn of changing it. This comment should be removed as it suggests a minor style change that doesn't meaningfully improve the code.
2. .github/workflows/linear-research-tickets.yml:42
- Draft comment:
Using 'exit 0' on API failure silently defaults capacity to zero. Confirm if this behavior is intentional. Otherwise, consider failing the job (or at least logging a more prominent error) to alert on API issues. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% Looking at the full context, this is a WIP limit check step. If it fails, it conservatively prevents new tickets by setting available_slots=0. This seems like reasonable defensive programming. Failing the job would prevent any ticket processing, which could be more disruptive than gracefully degrading. The error is also logged clearly. The comment raises a valid point about error visibility. Silent failures can mask underlying issues that should be addressed. However, the current behavior is an intentional graceful degradation pattern. The error is logged and the system fails safely by preventing new tickets rather than failing completely. The comment should be deleted. The current error handling is a reasonable design choice with clear error logging and safe fallback behavior.
3. .github/workflows/linear-research-tickets.yml:87
- Draft comment:
Quote the output substitution for available_slots to prevent any word-splitting issues, e.g. available_slots="${{ steps.check-wip.outputs.available_slots }}". - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While quoting shell variables is generally good practice, GitHub Actions handles the context variables (${{ }}) specially and ensures they are properly escaped. The value being assigned is a number (available_slots) that won't contain spaces or special characters. The current code works fine and adding quotes would be overly defensive. I could be wrong about GitHub Actions context handling. There might be edge cases where the output contains special characters that could cause issues. Looking at the code, available_slots is clearly a number (calculated from RESEARCH_WIP_LIMIT - review_count). There's no way for it to contain special characters that would cause word-splitting issues. The comment suggests an overly defensive change that isn't necessary given the context and type of value being handled.
4. .github/workflows/linear-research-tickets.yml:94
- Draft comment:
The syntax '${{ inputs.num_tickets || 10 }}' may not work as expected. Since a default is defined for the input, consider using the input directly or ensure the fallback value is correctly applied in the shell context. - Reason this comment was not posted:
Comment was on unchanged code.
5. .github/workflows/linear-research-tickets.yml:38
- Draft comment:
The overall error handling in the WIP capacity check is robust, but consider if failing early (exit with non-zero) would be preferable over silently defaulting to zero capacity—this depends on how critical API reliability is in this workflow. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The current behavior is intentionally defensive - it assumes no capacity when the API fails rather than failing the whole workflow. This is likely the desired behavior since: 1. The workflow runs on a schedule every 15 minutes 2. The workflow handles multiple tickets in parallel 3. The code has proper error logging 4. Temporary API failures shouldn't break the entire pipeline The comment raises a valid point about error handling philosophy. In some cases, failing fast can help catch issues earlier. However, the current graceful degradation approach is well-documented and seems intentionally designed for reliability. The error is properly logged and the behavior is clear. The comment should be deleted. The current error handling approach is a valid design choice and there isn't strong evidence that failing fast would be better.
Workflow ID: wflow_Xps47MZWuDi7kQZS
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
What problem(s) was I solving?
The research workflow was processing all available tickets without considering the capacity to review them, potentially creating a bottleneck in the review phase. This could lead to a growing backlog of tickets awaiting review while new research continued to be performed.
What user-facing changes did I ship?
How I implemented it
RESEARCH_WIP_LIMIT) for easy adjustmentHow to verify it
gh workflow disable/enableDescription for the changelog
Add WIP limit of 5 for tickets in "research in review" status to prevent review queue bottlenecks
🤖 Generated with Claude Code
Important
Adds a WIP limit of 5 for 'research in review' tickets in GitHub Actions workflow to prevent bottlenecks.
.github/workflows/linear-research-tickets.yml.RESEARCH_WIP_LIMITenvironment variable.This description was created by
for 2bf5c68. You can customize this summary. It will automatically update as commits are pushed.