🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Projects

Body

Summary

In an org I admin (Untie-it-Technologies), newly-created Projects v2 items — drafts via the UI, drafts via addProjectV2DraftIssue, and Issues added via addProjectV2ItemById — all return 201 Created and persist in the database, but don't appear in any view, in the project's items list, or in projectV2.items paginated queries until something else triggers a partial cache invalidation. This affects multiple projects in the org. Started ~2026-05-06T12:38 UTC.

Why I think the data is fine, just not indexed

• node(id: "PVTI_...") GraphQL queries return the full item with field values, including for items that aren't visible in any view.
• • The deletion-confirmation dialog when deleting a project correctly reports the count of drafts it will remove — even when the API listing was reporting 0. (We deleted a copy project with 26 drafts that the API was reporting as empty.)
• • Each delete_project_item or add_project_item mutation seems to invalidate the stale read cache for some items: the visible count went 16 → 17 → 20 → 27 → 30 across our maintenance ops, with previously-hidden items showing up at each step. We never got it fully consistent.

Reproduction (just performed, today)

1. Created issue in a repo via REST → 201.
2. 2. Added it to project 21 via addProjectV2ItemById → 201, returned a project item ID.
3. 3. Queried projectV2.items(first: 100, query: "<title>") → returned the item correctly.
4. 4. Loaded the project's saved view in the browser → total count incremented (27 → 30) but the new item card is not rendered on the board.
      Same symptom for UI-created drafts: POST /memexes/{project_id}/items returns 201, item is fetchable by ID, but the views don't render it.

Likely trigger

A series of project_field.delete / project_field.create operations on a different project in the same org on 2026-05-06 around 12:38–12:40 UTC. After those operations, all newly-created items in any project owned by this org appear to enter the same stuck-cache state. We did NOT do field deletes on the affected projects directly. Also coincides with multiple GitHub status incidents on May 6.

Fingerprint

• Field IDs in the affected project show a gap (489–491 missing), consistent with deleted/recreated fields at some earlier point.
• • A copy of the affected project (made via Projects UI "Make a copy") inherits the same symptom: items added to the copy are also not rendered, even though the copy reported it had inherited 26 drafts at deletion time.

Ask

1. Is project_field.delete on an actively-used project a known trigger for read-index staleness?
2. 2. Can the index be force-rebuilt for an affected project, or do we need to wait for natural cache eviction?
3. 3. Is there a known incident or recent change to the Projects v2 read path that we should be aware of?
      Happy to share project node IDs and request_ids privately if a GitHub Projects engineer wants to look. Posting publicly because the symptom is reproducible and others may be hitting it.

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.