pingdotgg / pingdotgg/t3code

[Bug]: PR URLs cannot be linked to threads in non-Git parent workspaces

Open
#9,435 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
23k
Forks
5.9k
Avg merge
11h 14m
Merged PRs (30d)
357

Description

Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/web (including the desktop app's shared web UI)

Steps to reproduce
  1. Create a workspace directory that is not itself a Git repository but contains multiple repositories:

    ~/work/
      repo-a/.git/
      repo-b/.git/
    
  2. Add ~/work to T3 Code as one project. This is useful for cross-repository threads that need to work in several child repositories from one parent directory.

  3. Start a thread in that project.

  4. Put a pull request URL for one of the child repositories in the thread, for example https://github.com/org/repo-a/pull/123.

  5. Right-click the rendered PR link.

Expected behavior

The context menu should offer Link to thread, as documented and implemented by #8160. The PR URL already identifies the host, repository, and PR number.

If T3 requires a project association to fetch PR state, it should resolve a matching child repository or let the user select/register the matching repository instead of silently removing the link action.

This workflow previously allowed me to associate a PR with the thread when its URL appeared in the conversation.

Actual behavior

The context menu does not offer Link to thread. A PR can only be linked when its repository already matches a separately registered T3 project in the same environment.

The non-Git parent project has no repositoryIdentity, and T3 does not discover its child repositories for this lookup, so a cross-repository thread cannot be associated with any of their PRs.

Source-level diagnosis

Current main parses the PR URL in ChatMarkdown.resolveThreadPullRequest, then calls findProjectForChangeRequest across registered projects in the thread's environment. If no project matches, it returns null, which makes threadLinkAction undefined and omits Link to thread from the context menu:

The persisted ThreadLinkedPullRequest also requires a projectId, so the current contract cannot represent a URL-linked PR that has no separately registered T3 project.

Impact

Major degradation or frequent failure

Cross-repository threads are the reason to use a non-Git parent workspace. Those threads lose PR status in the sidebar and cannot auto-settle when the PR merges unless every child repository is also registered as a separate T3 project.

Version or commit

Current desktop app; exact installed build unavailable. Confirmed in source on main at fff33f9e851912363c5b1f3ac65598be35eb5f0d.

Environment

macOS, T3 Code desktop/shared web UI, GitHub pull requests, non-Git parent workspace containing multiple child Git repositories.

Logs or stack traces
No relevant logs. The link action is omitted by the client-side project lookup.
Screenshots, recordings, or supporting files

None.

Workaround

Register every child repository as its own T3 project. Once a child has a matching repositoryIdentity, the parent-workspace thread can find that project in the same environment and offer Link to thread.

This is cumbersome for directories containing many repositories and does not preserve the intended single-project, cross-repository workflow.

Related work
  • #8160 added durable PR/thread linking from a PR URL in chat and documents the right-click Link to thread workflow.
  • #8488 adds link/unlink actions from the PR detail panel, but it still starts from a PR associated with a known project and does not address non-Git parent workspaces.
Follow-up: linked PR number is missing from the thread list

Registering the child repository as a separate T3 project in the same environment restores the Link to thread action in the non-Git parent thread. The link action completes, confirming that the project lookup described above is the blocker for creating the association.

However, the linked PR number is still not displayed on that thread's row in the thread list/sidebar.

Additional reproduction
  1. Register the child repository as its own T3 project.
  2. Return to a thread whose workspace is the non-Git parent directory.
  3. Right-click the child repository's PR URL and choose Link to thread.
  4. Inspect the parent thread's row in the thread list.
Expected

The linked PR number and state should appear on the thread row, which is part of the behavior described by #8160. The linked PR should remain visible even though the thread's own project is the non-Git parent and the linked PR's projectId belongs to the registered child project.

Actual

The association can be created, but no linked PR number appears in the thread list. This makes the child-project workaround incomplete: it restores the link command without restoring the sidebar visibility that makes the association useful.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in apps/web/src/components/ChatMarkdown.tsx at resolveThreadPullRequest and the context-menu gate, then read apps/web/src/lib/openPullRequestLink.ts and packages/contracts/src/orchestration.ts. Compare the behavior documented by #8160; done means a PR URL in a non-Git parent workspace can be linked to its thread and the linked PR number and state remain visible in the thread list.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, typescript
Domain
frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.