fix: eliminate cache-memory dependency in update-instructions workflow#8739
Open
vhvb1989 wants to merge 1 commit into
Open
fix: eliminate cache-memory dependency in update-instructions workflow#8739vhvb1989 wants to merge 1 commit into
vhvb1989 wants to merge 1 commit into
Conversation
Replace the cache-memory tool (used to store last-run.txt) with a GitHub API query for the last successful workflow run. This fixes the false-positive cache-miss failure on first run, where the agent correctly reported missing_data/cache_memory_miss but gh-aw's detection layer interpreted it as a prompt misconfiguration. The workflow run history is the natural, always-available source of truth for "when did this last succeed" — no external state to seed, evict, or misread. This also avoids the 7-day cache eviction risk that could cause repeated first-run behavior on a weekly schedule. Fixes #8702 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
vhvb1989
added
bug
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the Update Instructions From PR Reviews agentic workflow definition to remove reliance on cache-memory and instead derive the “since last run” starting point from GitHub Actions workflow run history.
Changes:
- Removes the
cache-memorytool dependency and the “record the run” step (state now lives in workflow run history). - Adds
actions: readpermission and updates the range-determination logic to use the last successful run timestamp.
Comment on lines
+155
to
+159
| 2. Otherwise, use the GitHub tools to list recent workflow runs for **this | ||
| workflow** (`update-instructions-from-pr-reviews`) in the repository this | ||
| workflow runs in. Find the most recent **successful** (completed with | ||
| `conclusion: success`) run and use its `created_at` timestamp as the | ||
| starting point — mine PRs merged after that date. |
Comment on lines
+1
to
+5
| --- | ||
| name: Update Instructions From PR Reviews | ||
| on: | ||
| schedule: | ||
| # NOTE: Using the fuzzy form for scheduling lets gh-aw jitter the exact minute |
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
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
Fixes #8702
Replace the
cache-memorytool with a GitHub API query for the last successful workflow run in theupdate-instructions-from-pr-reviewsagentic workflow.Problem
On first run,
last-run.txtdidn't exist in cache. The agent correctly calledmissing_datawithcache_memory_miss(as instructed by the cache-memory system), but gh-aw's detection layer interpreted this as a prompt misconfiguration rather than a legitimate first-run condition.Fix
Eliminate the cache entirely. Instead of reading/writing
last-run.txtin cache-memory, the agent now queries the GitHub API for the most recent successful run of this workflow to determine the PR range starting point.Changes
cache-memory:tool from the workflow frontmatteractions: readpermission so the agent can list workflow runsWhy not just fix the prompt?
The cache-memory approach is inherently fragile for a weekly workflow:
Per richardpark-msft's comment: "If you can get it to just query that detail directly you can eliminate a dependency on that cache altogether."