✍️ (posts): rename request-lifecycle post and add draft for why workflow failing

- renamed: content/tech-journal/post-04-request-lifecycle/index.md → content/tech-journal/post-05-request-lifecycle/index.md
- added: content/tech-journal/post-04-why-workflow-failing/ (draft)

Author: socrabytes

content/tech-journal/post-04-why-workflow-failing/context-timeline.png

@@ -0,0 +1,167 @@
+---
+title: "Why Your Workflow Isn’t Failing Where You Think It Is"
+slug: "why-workflow-failing"
+date: 2025-05-04
+description: "-----"
+summary: "------"
+categories: ["Automation & Devops"]
+tags: ["github-actions", "CI/CD", "gh CLI", "debugging"]
+featureAlt: "----"
+draft: true
+---
+
+When a _GitHub Actions workflow_ that had been working fine for months suddenly failed, I went down a familiar rabbit hole of false assumptions, vague errors, and misleading logs. This post details the troubleshooting journey, the kind that initially screams ***“runner environment change,”*** but ends in a quiet whisper: ***“your token expired.”***
+
+## Context: Automation That Moved 🐛 Issues
+For context, I had a GitHub Actions workflow using `gh` (GitHub CLI) to automatically move issues labeled `bug` into a "Bugs" column on my GitHub Project board (#6). This workflow ran fine for months—until mid-April 2025, when it silently failed.
+
+![Context Timeline Infographic](context-timeline.png "Context Timeline Infographic")
+
+- **Workflow Name:** `🐛 Auto Bug Column Management`
+- **Purpose:** Move issues labeled `bug` to a "Bugs" column in GitHub Projects (Project #6)
+- **Tools:** GitHub Actions, `gh` CLI, shell scripting, PAT-based auth
+- **Initial State:** Everything worked smoothly until mid-April 2025
+
+---
+
+## Initial Suspect: A Changing Environment
+
+Like many others, I use `ubuntu-latest` for my GitHub Actions runners for convenience. Around the time my workflow failed (mid-to-late April 2025), I noticed warnings appearing in my Actions logs about `ubuntu-latest` preparing to point to the new `ubuntu-24.04` LTS, updating from `ubuntu-22.04`.
+
+{{< screenshot src="ubuntu-latest-warning.png" alt="GitHub Actions warning about ubuntu-latest" >}}
+
+This seemed like the obvious culprit. Runner environment changes are a common source of workflow failures. I also checked the runner image software lists (like those tracked in actions/runner-images issues, e.g., #10636) and noted potential differences in pre-installed software, including the gh CLI version itself (my local gh 2.68.1 vs. runner versions potentially being 2.69.0 or 2.70.0).
+
+My first logical step was to eliminate this variable. I updated my workflow YAML:
+
+```YAML
+jobs:
+  move_bug_issues:
+    # ...
+    # runs-on: ubuntu-latest # Changed from this
+    runs-on: ubuntu-22.04  # To this
+    # ...
+```
+I reran the workflow, confident this would likely resolve the issue.
+
+## Hitting a Wall: The Cryptic Error
+
+Pinning the runner to `ubuntu-22.04` didn't fix it. The workflow failed again, specifically at the step designed to find the project item ID associated with the labeled issue:
+
+```YAML
+- name: Retrieve Project Item
+        id: get-item
+        run: |
+          ITEM_ID=$(
+            gh project item-list "6" \ # Project Number 6
+              --owner "socrabytes" \   # My username
+              --limit 100 \
+              --format json \
+              --jq ".items[] | select(.content.number == $ISSUE_NUMBER) | .id"
+          )
+          # ... rest of script ...
+        env:
+          GH_TOKEN: ${{ secrets.PROJECT_TOKEN }}
+          OWNER: "socrabytes"
+          ISSUE_NUMBER: ${{ github.event.issue.number }}
+          PROJECT_NUMBER: "6"
+```
+
+{{< screenshot src="github-actions-error.png" alt="GitHub Actions error message" >}}
+
+The error message wasn't immediately helpful regarding the runner environment: unknown owner type. Why would it suddenly not know the owner type for "socrabytes"? This didn't feel like a gh version compatibility issue on the surface.
+
+## Isolating the Variable: Local 🆚 Remote Testing
+
+If it wasn't the runner OS or (maybe) the `gh` version difference, I needed to confirm the command itself was still valid.
+
+1. **Test Locally (Current Version):** I ran the equivalent `gh project item-list` command on my local machine, which had `gh version 2.68.1` installed via Homebrew. **Result: It worked perfectly.**
+2. **Test Locally (Upgraded Version):** To further rule out a breaking change in newer `gh` versions, I upgraded my local CLI (`brew upgrade gh`) to `gh version 2.71.1`. I ran the command again locally. **Result: It *still* worked perfectly.**
+
+This was a critical finding. If the command worked locally with both the older version *and* a version newer than the one on the runner, the `gh` version number itself was highly unlikely to be the direct cause. The problem had to be specific to the GitHub Actions execution **context**.
+
+## Digging Deeper: Checking Authentication in Actions
+
+My workflow uses a Personal Access Token (PAT) stored as a secret (`secrets.PROJECT_TOKEN`) to authenticate `gh` commands, allowing it to modify my project board. Although I knew the PAT *should* be valid (it hadn't been changed recently), the next logical step was to explicitly verify authentication *within the runner environment*.
+
+I added a simple debug command to the failing step: `gh auth status`.
+
+```YAML
+- name: Retrieve Project Item
+        id: get-item
+        run: |
+          echo "gh cli version: $(gh --version)" # Added for good measure
+          echo "Debugging OWNER: $OWNER"
+          echo "Checking auth status:"          # <-- Added this line
+          gh auth status                      # <-- Added this line
+
+          # Original command follows...
+          ITEM_ID=$(
+            gh project item-list "$PROJECT_NUMBER" # ... etc
+          )
+          # ...
+        env:
+          GH_TOKEN: ${{ secrets.PROJECT_TOKEN }}
+```
+## The "Aha!" Moment: The Real Culprit
+
+The output from this debug step in the Actions log was crystal clear:
+```CLI
+gh cli version: gh version 2.70.0 (2025-04-15)
+https://github.com/cli/cli/releases/tag/v2.70.0
+Debugging OWNER: socrabytes
+Checking auth status:
+github.com
+  X Failed to log in to github.com using token (GH_TOKEN)
+  - Active account: true
+  - The token in GH_TOKEN is invalid.
+Error: Process completed with exit code 1.
+```
+
+There it was: **"The token in GH\_TOKEN is invalid."** The `unknown owner type` error was simply a downstream effect of `gh` failing to authenticate properly *before* it could even process the project and owner details.
+
+**The Resolution: A Simple Token Refresh**
+
+Why was the token invalid? I checked my repository secrets – the `PROJECT_TOKEN` secret itself showed "Last updated 4 months ago".
+
+**(Optional: Insert Image `image_597009.png` here, showing the secrets list)**
+
+However, the "last updated" time for the *secret storage* doesn't reflect the *PAT's expiration date*. PATs are generated with specific lifetimes (e.g., 30, 60, 90 days, or custom). It was almost certain my PAT, likely created with a 90-day expiry, had simply expired.
+
+The fix was straightforward:
+
+1. Go to GitHub Developer Settings -&gt; Personal access tokens.
+2. Find the relevant (likely expired) token.
+3. Regenerate the token, ensuring it had the necessary `project` scopes. I chose a new 90-day expiration.
+4. Copy the new token value.
+5. Go back to the `youtube-digest` repository Settings -&gt; Secrets and variables -&gt; Actions.
+6. Update the `PROJECT_TOKEN` secret with the new token value.
+
+After updating the secret, I re-ran the workflow, and it executed perfectly.
+
+**Lessons Learned & Takeaways**
+
+This half-day troubleshooting journey reinforced several key points:
+
+- **Debug Systematically:** Don't get locked onto the first hypothesis, even if initial evidence seems strong (like runner update warnings). Methodically eliminate variables.
+- **Leverage Local Testing:** Comparing behavior locally versus in CI/CD is crucial for pinpointing environment-specific issues.
+- **Verify Authentication Early:** When CI/CD tools interact with APIs, especially if encountering strange errors, explicitly check the authentication status (`gh auth status` in this case) early in the debugging process.
+- **Error Messages Can Mislead:** The initial `unknown owner type` error sent me down the wrong path initially. The real error was hidden until authentication was explicitly checked.
+- **Manage Credential Lifecycles:** PATs expire! This incident highlighted the need for proactive management. Setting calendar reminders or documenting expiration dates is crucial, even for solo projects.
+
+**Conclusion**
+
+While the root cause – an expired PAT – was operationally simple, the path to diagnosing it involved navigating misleading clues and systematically ruling out other potential causes. It was a valuable reminder that sometimes the most obvious environmental changes aren't the culprit, and checking foundational aspects like authentication is key. Hopefully, sharing this journey helps someone else who encounters a similarly confusing workflow failure!
+
+---
+
+
+## 🐛 **The Problem**
+
+{{< lead >}}
+When a _GitHub Actions workflow_ that had been working fine for months suddenly failed
+{{< /lead >}}
+
+{{< screenshot src="github-actions-error.png" alt="GitHub Actions error message" >}}
+
+The error message was vague: "The workflow is not authorized to run a workflow file."