Replying on issues just not working

[gregor-tokarev]

Description

When I'm leaving comments on the issue from diffkit, it's not added in actual issue on diffkit, but it will be added on the GitHub. So integration layer works, but something wrong with diffkit API.

Steps to Reproduce

1. go to any issue
2. write reply and hit send

Expected Behavior

an reply to show up..

Actual Behavior

nothing happening even after update

Screenshots

Export-1777649572985.mp4

Environment

• Browser: arc
• OS: macos

[tembo]

Worth narrowing this to whether the stale read is happening on the dashboard refetch, not GitHub refusing the mutation: posting already uses octokit.rest.issues.createComment and the UI calls invalidateQueries on success (see DetailCommentBox / reply flow, CommentReplyForm).

The issue detail route loads getIssuePageData (embedded comments via GraphQL → resource issues.pageData.graphql.v2, split KV mode) (githubIssuePageQueryOptions + IssueDetailPage). createComment only busts issues.comments / pulls.comments and bumps cache namespaces; it does not bump the github_revalidation_signal timestamps that drive isSignalNewerThanCache in getGitHubResourceLocalFirst, while a webhook issue_comment path does include issue:owner/repo#n (github-revalidation.ts). So after an in-app comment, the React Query invalidation may refetch the server fn and still hit a locally cached issue page payload that predates the new comment until something else timestamps that signal or the legacy row ages out—that matches “visible on github.com but not in DiffKit until something else refreshes.”

Things that would validate the theory quickly: reproduce with network tab showing the / server fn response right after send; compare to issues.createComment succeeding. Fix direction to consider: after a successful comment, also markGitHubRevalidationSignals for githubRevalidationSignalKeys.issueEntity (and pullEntity when the number is a PR), and/or explicitly bustGitHubCache for issues.pageData.graphql.v2 (and any REST issue-page resources) for that issue.

Related background on keeping entity-scoped data in sync with signals: #160, #161, #179.