Replying on issues just not working #182

Activity

1. gregor-tokarev

   added

   bugSomething isn't workingSomething isn't working

   on May 1, 2026
2. tembo commented on May 1, 2026

   

   temboBot

   on May 1, 2026 – with Tembo

   Contributor

   More actions

   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.