Skip to content

Investigate GitHub Projects item-list and saved-view inconsistency blocking #33 #56

Closed
Closed
Investigate GitHub Projects item-list and saved-view inconsistency blocking #33#56
Milestone
v0.1.0

Description

@monancho
monancho
opened on Sep 23, 2026

Objective

Resolve or explicitly disposition the GitHub Projects item-list/view inconsistency blocking #33's acceptance QA. Preserve Project #2 and existing item field history.

Current evidence

On 2026-09-23, direct Issue-to-Project and item-by-ID reads found #7 and #45 as unarchived items with saved Status, Scope Origin, and Estimate, while Project item-list and saved views omitted them. #45 became visible in the Project list at 13:53 UTC after an earlier omission; #7 was still absent. Newly added #56 also had a direct unarchived Project item with correct fields but was not yet in the Project list. This is consistent with delayed Project indexing, but does not establish GitHub's internal cause. The saved Attention view also omitted #33 while its blocked label was present.

Scope

Completion conditions

Either:

  1. Project-side readback recovers: 32 total items (including Investigate GitHub Projects item-list and saved-view inconsistency blocking #33 #56), 30 v0.1.0 Issues in Release Overview and Hierarchy, 24 estimated Baseline leaves in Baseline Progress, one Added item (Investigate GitHub Projects item-list and saved-view inconsistency blocking #33 #56), and Investigate GitHub Projects item-list and saved-view inconsistency blocking #33 #56 visible in Attention while labeled blocked. Re-run Refine Dedicated Project views and compatible native automations #33 QA and record the result; or
  2. An explicit maintainer disposition records a verified GitHub platform limitation and the accepted change to Refine Dedicated Project views and compatible native automations #33/release acceptance. Do not silently declare the current undercount correct.

Constraints and prerequisites

Authority and decisions

The maintainer requested a separate tracking Issue and continuation of work on 2026-09-23. Diagnostic readback and issue-state reconciliation are authorized here. Contacting GitHub Support/Community or changing #33's acceptance/release gate requires an explicit further decision.

Activity

  1. monancho
    added this to the v0.1.0 milestone on Sep 23, 2026
  2. monancho
    added a parent issue on Sep 23, 2026
  3. monancho
    marked this as blocking on Sep 23, 2026
  4. monancho
    added
    blockedBlocked by a condition not represented as an Issue Dependency
    on Sep 23, 2026

  5. monancho commented on Sep 23, 2026

    @monancho
    monancho
    on Sep 23, 2026
    OwnerAuthor

    First investigation checkpoint — 2026-09-23 13:58 UTC

    Next action: recheck the Project and view lists after GitHub indexing has had time to catch up. Preserve the original item IDs and values. If the mismatch persists, prepare an exact reproduction for maintainer-authorized GitHub Support/Community escalation; do not close #33 or #56 on an undercounted view.

  6. monancho commented on Sep 23, 2026

    @monancho
    monancho
    on Sep 23, 2026
    OwnerAuthor

    Support-ready minimal reproduction (prepared locally; not submitted externally)

    Project: https://github.com/users/monancho/projects/2
    Repository Issue: #7
    Observed on 2026-09-23 after direct membership and field writes were verified.

    query($owner: String!, $repo: String!, $project: Int!, $missing: Int!, $search: String!) {
  repository(owner: $owner, name: $repo) {
    issue(number: $missing) {
      number
      projectItems(first: 10) {
        nodes { id isArchived project { number } }
      }
    }
  }
  user(login: $owner) {
    projectV2(number: $project) {
      items(first: 100, query: $search) {
        totalCount
        nodes { content { ... on Issue { number } } }
      }
    }
  }
}

    Variables: owner=monancho, repo=github-workflow, project=2, missing=7, search=7.

    Actual response summary: Issue #7 has Project item PVTI_lAHOCnRQ6s4BkXGqzg8VMyI, isArchived=false, project.number=2; the same Project's filtered items connection returns totalCount=0. The unfiltered Project connection and REST item list also omit #7. Direct item GET succeeds. Expected: the active item appears in the Project's items connection and matching saved views.

    Please investigate Project forward-list/view materialization or identify a supported repair. The current direct item must retain its fields and history. No item deletion, Project recreation, or external Support/Community post has been performed for this report.

  7. monancho commented on Sep 23, 2026

    @monancho
    monancho
    on Sep 23, 2026
    OwnerAuthor

    Recheck and safe repair attempt — 2026-09-23 14:09 UTC

    Fresh independent reads still show 30/32 Project items. The unfiltered Project list omits #7 and #56; Release Overview/Hierarchy show 28/30, Baseline Progress 23/24, Added Scope 0/1, and Attention 0/1. Direct Issue-to-Project reads continue to show #7 (PVTI_lAHOCnRQ6s4BkXGqzg8VMyI) and #56 (PVTI_lAHOCnRQ6s4BkXGqzg8V09A) as unarchived items in Project #2 with the correct values. The unfiltered list already omits them, so changing a saved-view filter cannot recover these rows.

    I tried the documented REST PATCH /users/monancho/projectsV2/2/items/{id} path on each existing item using only its current field values: #7 = Done/Baseline/5 and #56 = In Progress/Added/2. Both calls returned the original item IDs; separate GraphQL readback confirmed all values and membership unchanged. The Project list still returns 30 and omits both. Earlier idempotent item-add, #7 archive/restore, and #7 position update also did not repair the forward list. No item was deleted or recreated.

    There is no verified client-side repair from these attempts. #45 did appear after a delay without destructive action, so allow further GitHub indexing time and recheck against the completion counts in this Issue. If #7/#56 remain absent after that, use the prepared minimal reproduction above for an authorized GitHub Support/Community escalation. #33 remains blocked by this Issue.

  8. monancho commented on Sep 23, 2026

    @monancho
    monancho
    on Sep 23, 2026
    OwnerAuthor

    Timing and PR hypothesis check — 2026-09-23 15:11 UTC

    The date changed to 2026-09-24 in KST, but only about one hour has elapsed since the prior 14:09 UTC checkpoint. Exact direct item creation times: #7 at 13:06:16 UTC; #56 at 13:54:04 UTC. The previously omitted #45 was created at 11:08:23 UTC and had appeared in the Project-side list by 13:53 UTC, about 2 hours 45 minutes later. These timestamps justify one later recheck rather than treating the date change itself as a full-day persistence test.

    The PR-sharing explanation is ruled out: all 30 items currently returned by Project #2 are Issue content, and the direct items for #7 and #56 also have content.__typename = Issue with their own distinct Project item IDs. #56 has no linked PR. The mismatch remains between the Issue-to-Project/direct-item reads and the Project's forward list/views.

    Next checkpoint: after approximately 16:55 UTC (01:55 KST), when #56's item has had about three hours to materialize. If #7/#56 are still absent then, update this Issue with the counts and use the prepared reproduction for an authorized GitHub Community or Support report. Preserve the existing item IDs and fields.

  9. monancho commented on Sep 23, 2026

    @monancho
    monancho
    on Sep 23, 2026
    OwnerAuthor

    Root-cause evidence update — 2026-09-23 15:18 UTC

    GitHub's official unresolved incident feed now provides a direct platform explanation: incident 8zc63m64hy36, started 10:11 UTC, remains investigating; the 13:35 UTC update says users may see stale Project search results while GitHub works to increase indexing speed. Source: https://www.githubstatus.com/api/v2/incidents/unresolved.json (incident link: https://stspg.io/m1ps7yrhp4n8). The general component summary can say operational while this incident remains unresolved, so the earlier All Systems Operational snapshot did not rule out Project indexing lag.

    The affected Project items were created after incident start: #7 at 13:06:16 UTC and #56 at 13:54:04 UTC. #45, created at 11:08:23 UTC, appeared in the Project-side list later without deletion. This timing and our direct-item/forward-list mismatch are consistent with the reported incident; GitHub has not identified our individual items by name, so treat causation as a strong inference rather than a confirmed account-specific diagnosis.

    Read-only request IDs captured at 15:16:51 UTC for GitHub investigation:

    The list still omits #7/#56 while direct reads succeed. Do not keep mutating or delete/re-add items during the active indexing incident. Supersede the fixed 16:55 UTC checkpoint with this rule: recheck after GitHub marks the incident resolved, using 32 Project items, 30 release Issues, 24 Baseline leaves, one Added leaf, and one Attention item as the acceptance counts. If the mismatch remains after incident resolution and indexing catch-up, use the prepared reproduction and request IDs in a GitHub bug report/Community discussion; leave #56 blocked and #33 dependent until verified.

  10. monancho commented on Sep 23, 2026

    @monancho
    monancho
    on Sep 23, 2026
    OwnerAuthor

    Additional non-destructive repair attempt — 2026-09-23 15:20 UTC

    I tried the documented REST add item to user-owned Project endpoint once for each affected Issue using its existing Issue database ID, without removing the Project association. GitHub returned HTTP 422 Content already exists in this project for both #7 and #56. Request IDs: #7 D295:1F40F4:604CD1:814F49:6AB3EF13; #56 D29D:53D53:60F06C:81F4D6:6AB3EF20.

    Separate post-attempt readback confirms the original item IDs, unarchived state, and values are unchanged: #7 = Done/Baseline/5; #56 = In Progress/Added/2. The Project forward list remains 30/32 and omits both. This route cannot repair the active incident's list materialization, but confirms GitHub recognizes both associations. No item was deleted, recreated, or moved.

    GitHub's official incident 8zc63m64hy36 remains unresolved and explicitly reports stale Project search results while indexing catches up. Stop local write retries; recheck after the incident is resolved, then escalate with the prepared reproduction and request IDs if the list remains incomplete.

  11. monancho commented on Sep 23, 2026

    @monancho
    monancho
    on Sep 23, 2026
    OwnerAuthor

    GitHub recovery request submitted: community/community#193185 (comment)

    Verified after submission (2026-09-23 UTC): Project #2's GraphQL forward item list still returns 31 items and omits #56, while the direct #56 item remains active and linked. GitHub's Projects incident 8zc63m64hy36 is still investigating and reports stale Project search results: https://www.githubstatus.com/api/v2/incidents/unresolved.json

    The request includes the direct/list mismatch, saved-view counts, item and request IDs, prior safe recovery attempts, and a request to reindex the Project or confirm incident backfill. Keep this issue blocked until the forward list and saved views show #56. Then recheck #33's view acceptance criteria and the dependent #26 release checklist.

  12. monancho commented on Sep 23, 2026

    @monancho
    monancho
    on Sep 23, 2026
    OwnerAuthor

    Project readback recovered — 2026-09-23 22:29 UTC

    The original #56 Project item PVTI_lAHOCnRQ6s4BkXGqzg8V09A (REST 253088720) is now unarchived and present in the forward Project list. Its Issue link, milestone v0.1.0, blocked label, Status=In Progress, Scope Origin=Added, and Estimate=2 read back correctly. No Project item was deleted or recreated.

    Saved-view API QA now passes the recorded acceptance counts:

    GitHub incident 8zc63m64hy36 is still investigating and its latest update mentions delayed Project label updates. The account-specific list/view mismatch has recovered; internal cause and whether the GitHub Community request contributed are unconfirmed. Remove this resolved external blocker and close this investigation, then finish #33 acceptance QA.

  13. monancho
    removed
    blockedBlocked by a condition not represented as an Issue Dependency
    on Sep 23, 2026
  14. monancho
    closed this as completedon Sep 23, 2026

  15. monancho commented on Sep 24, 2026

    @monancho
    monancho
    on Sep 24, 2026
    OwnerAuthor

    한국어 추적 요약

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions