Graphite Community

Hi there! Any `gt` command you're attempting to run is causing this error?

Hi, almost every `gt` command triggered this error, such as `gt log`, `gt ss`, `gt bc`, and so forth.

Firstly, I reset the repository and temporarily resolved the issue, but it seems that it occurred due to a recursive tracking between branches inadvertently.

I’m definitely still getting 403s and in other scenarios too. Since it seems auth related, let me try setting up graphite auth to CLI again.

```2023-06-22T02:13:11.050Z: ExitFailed: Unexpected server response (403).

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}
    at requestServerToSubmitPRs (/snapshot/graphite-cli/apps/cli/dist/src/actions/submit/submit_prs.js)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async submitPullRequest (/snapshot/graphite-cli/apps/cli/dist/src/actions/submit/submit_prs.js)
    at async submitAction (/snapshot/graphite-cli/apps/cli/dist/src/actions/submit/submit_action.js)
    at async Object.run (/snapshot/graphite-cli/apps/cli/dist/src/commands/stack-commands/submit.js:16:9)
    at async graphiteHelper (/snapshot/graphite-cli/apps/cli/dist/src/lib/runner.js)
    at async /snapshot/graphite-cli/apps/cli/dist/src/lib/runner.js
    at async Tracer.span (/snapshot/graphite-cli/apps/cli/dist/src/lib/utils/tracer.js)
    at async graphiteInternal (/snapshot/graphite-cli/apps/cli/dist/src/lib/runner.js)
    at async Object.handler (/snapshot/graphite-cli/apps/cli/dist/src/commands/stack-commands/submit.js:15:5)```


image.png

seems like maybe there’s some kind of outage happening affecting me?

Saw your string of messages earlier! Let me know if you're still having issues with the CLI/app and we'll take a look. We had a brief incident earlier yday that _might_ have been related but also possibly not

Hmm do you mind sharing some screenshots of your reviewers panel here/in PM? This shouldn't be expected behavior but there might be something else going on here

typeahead does not seem to work at all for me for some reason

Do you see any error messages on the console when typing anything into this box?

And also, are you part of a very large org?

let me check the console, and my org is 4 people big

Could you PM me a link to this PR/a PR this is happening on?

I'd expect `gt dp` to always be instant since it has very little to do.

Oooh, so it looks like the brew version is slow, but installing with npm is faster. No idea why this'd be though... I'm unblocked now, after running:
```brew remove withgraphite/tap/graphite;
npm install -g @withgraphite/graphite-cli```

that is weird! cc <@U02RREE9GKH> who is OOO but might have thoughts when he's back next week!

hmmmm, this isn't great — we switched to using `pkg` to create a binary for the brew version recently and I hope that's not the cause.  I'll investigate

I <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1687888720390709|just posted> about some similarly weird automerge behavior which might be related

i tried it on my machine btw, and the brew version is definitely slower as reported

Wow, thank you for trying that. I was worried I was imagining things!

nope! for now can you switch to the `npm` version?

yup, I'm on it now and my world is happier

:confused: my world is unhappy though, I hope this doesn't mean that `pkg` is a dead end.  Thanks for flagging this!

oh no Jacob :disappointed: :disappointed:

no obligation of course, but I'd be super curious for a readout about why if you figure it out

So I'm not 100% sure why this was only happening for you with the brew version, because I've done some testing and I'm seeing about the same speeds on both the live npm and brew versions at the moment for `time gt ls` — but there were some issues affecting perf that I've found and that I'll be pushing a release to fix. We'll leave `pkg` in place on brew for now and see how that goes.

Still working on our release process since we moved development into our monorepo, but it should be in your hands by the weekend!

Should be the final followup here – I realized that the reason the brew version was much slower is because we were building an x64 binary and distributing that to all macos users — as of v0.22.1 we now build both an x64 and arm64 binary and brew chooses the correct one to install depending on your CPU architecture, which should resolve the last vestige of any pkg-related slowness

CleanShot 2023-06-22 at 13.46.05@2x.png

fyi i think we're reverting to left aligning the description for now
cc <@U04AP0M9AES> though - want to look into the `overflow` content being cut off when you do?

oops, that is definitely not intended — we’ll get that fixed for you!

I personally want some kind of max-width applied so that on my wide monitor I don't have to move my head side to side to see all the text. :slightly_smiling_face:

But also don't want it cut off on the edges for those times where I have a narrow window :rolling_on_the_floor_laughing:

i totally agree on the `max-width` (ultrawide here)

<@U02PSKGK4TS> what browser? i can't repro the text cut-off

how divergent is arc from chrome in terms of rendering bugs etc?

CleanShot 2023-06-22 at 15.00.37@2x.png

Not so much. I can get a narrow enough window for the PR to cut off the text on the side.

would you cut and paste me the exact markdown in your PR description?

Interestingly Chrome isn't displaying centered but rather left aligned. Did that already get changed?

that _just_ got changed back :slightly_smiling_face:

the fix for this is out and should be available soon!

CleanShot 2023-06-22 at 14.46.30.mp4

Yikes - Cc <@U05597DUYDD> / <@U04AP0M9AES>

interesting, i was in here last re: cursor positions, i can add it to my queue

more-context.mov

i have a repro on my end, and also for more fun context, it _works_ on a single line

i was able to see both
• start of comment behavior
• nuking the whole comment behavior


on the plus side, my work on fixing *undo* for things like @-mentions is really paying off now

fix-comment.mov

<@U02PSKGK4TS> following up, i have a fix in the merge queue, so whenever it rolls all the way to prod it should be fixed!

Hi Joseph, Can you DM the PR this happened on and I can investigate?

I had something similar happen (don't remember the PR), where I enabled "merge when ready" while CI checks were still going, then thought better of it and clicked to disable "merge when ready". The UI was weird for a moment (can't remember how), and then Graphite merged the PR before CI checks were complete.

I chatted with Joseph offline. What was happening is that some of the CI checks were not marked as required. "merge when ready" will only wait for required CI checks to be successful before merging. If there are CI checks that are not required, "merge when ready" will not wait for them.

As a team we are investigating if there are ways we can make it more clear what is happening for cases like this.

this was user error, but we *thought* our checks were required bc we had enabled checks required branch protection. but we had *not* explicitly selected all the checks in GH settings, so in reality all of our checks were optional :disappointed:

I’d expect optional checks to *complete* tho - optionality only means it doesn’t matter if it fails.

fwiw, GitHub's "merge when ready" option behaves the same...

same how, in that it merges before optionals are complete? or that it merges once all checks are done, but ignores fail status of optionals?

<@U02HMBYM7LL> we’re considering this as a user option setting. But thinking it through… if it’s going to merge regardless of the completed optional status (i.e. regardless if passing or failing), then we’re simply delaying merging. Is this the desired behavior? If so, can I get a better understanding of why you prefer waiting for optional checks to complete as opposed to merging immediately when all required checks pass?

for a number of reasons.

one of them is that github shows how many checks were completed at merge time, so it look shoddy if it's less than 100%.

another is that those optional checks are still important, and i still want them to pass, and once the PR merges, the branch will be auto-deleted, which means that those checks might *fail* - especially since the checkout step may not have run yet.

so merging immediately could actually cause the optional checks to *fail* when they'd otherwise pass

Got it, thanks for the additional context

&gt;  those optional checks are still important, and i still want them to pass,
1. Do you want it to merge if the optional checks fail as long as they complete before the merge happens?
2. If not, are you able to set them as required instead and have it wait until it passes to merge?


1. yes. they're optional, which means i want them to *run* but it's ok if they fail

Got it, thanks! We’ll probably add an option to wait for all checks to complete before merging

sounds great. altho i think that should still be the default, since it's safer

Just ran into the same thing, was very surprised. It actually ended up in a very annoying state where a branch higher in the stack merged into one of the lower branches after that lower branch was merged, but before the lower branch was deleted from GitHub.

So I've now had to play the revert/revert dance to pull that code back up and merge it to master manually. Quite frustrating tbh

"Merge when ready" was built to trigger as soon as the PR is allowed to merge (as someone mentioned above, it is at parity with GitHub automerge for unstacked PRs).
Out of curiosity, why aren't these checks required if you expect them to pass before merging?
I imagine to build what you want here, we'd need to build a more general "merge when X" system which might not be for a while, to be fully transparent...

As for the upstack branches merging before downstack branches have been deleted issue — that shouldn't happen <@U03FNT1FLP5> — can you DM me which PRs were involved, and i'll look into it?

<@U02RREE9GKH> i don't expect them to pass, i expect them to complete, because a check being non-required doesn't mean it can be skipped, it just means a failure will be ignored. to be fair tho i don't use "merge when ready" (mostly because github still lacks fast-forward-merge)

For us, they are required, but we sometimes need to merge quickly to fix bugs etc. as we’re still very small and want to be able to ship / iterate quickly. Specifically in cases of reverts etc. We still the same suite on deployment so in those scenarios we’re fine with it. As a result, you can merge to our master without approval.

I’ll DM you the PRs now Jacob, thanks :+1:

EDIT: They are required by us semantically, but not by GH

for us it was just a GH misunderstanding. we had enabled require checks on all our repos, but it was unclear that we had to opt-in to each check in repo settings to actually make them required. thats fixed now :sweat:

Hi Anton, we should only be showing merge strategies that are allowed on the repo. Can you DM me your coworkers github handle and a PR where you saw this and I will investigate?

hmm, let me check out settings, maybe someone re-enabled it

yep, someone did. sorry for the false alarm!

Screenshot 2023-06-22 at 23.24.40.png

Haha definitely not a distance issue...sorry this is happening though! <@U05597DUYDD> might be able to help you!

Hi <@U05DYD3D0CS>! Sorry about this - we're actively working on shipping a new onboarding experience that will definitely make this process less confusing.

Do you happen to know if your org has GitHub App installed?

Yes my org is using GitHub App authorization

Screenshot 2023-06-23 at 10.04.35 AM.png

Ok great, you can use these steps (bear with us while they're a bit confusing right now) to see your company's repos

(shoutout <@U03E0N4H2RG> for the instructions while we continue to make improvements here)

:wave: Apparently signed up flow changed recently and our doc is not up to date anymore.
Here is what one of our developers see.
Could you help us here?
Thanks a lot!

Hey Vincent! Thanks for flagging this, <@U02DGG36CSH> looks like this is the bug we saw earlier!

We're looking into this now - will keep you updated!

Identified the issue and working on getting a fix out!

Screenshot 2023-09-11 at 10.26.51 AM.png

Hey guys - you should be unblocked here! Directly from the org selection screen you should see a button that allows you to "authenticate the graphite app." Once you do so, you can come back to the page and you'll be able to see your organization in the list! (See image below)


Some context on the fix here: If you're a new Graphite user that's joining an organization that already has the Graphite App installed, you'll have to authenticate the Graphite App first in order for us to see that you're a member of the organization. In short, what we can/cannot see with the various authentication methods GitHub provides is a little hairy, and we're trying to abstract this complexity away from users as much as possible (hence the new flow). When you authenticate the Graphite App here, it's important to note that we'll only have access to your orgs on which the Graphite App has already been installed (and no others)!

Might have spoke a little too soon - there's one more bug we have to squash before this is entirely fixed, will follow up one more time. Thanks for bearing with us!!!!

<@U05DYD3D0CS> could you lmk if this worked for you?

Should be fixed!! Let me know if the above fix worked :pray: :pray: 

Hey Ricardo, Graphite takes a look at the code owner requirements from the branch you will eventually be merging into. Which will differ from what GitHub shows if you’re looking at an upstack PR

Hmmm... This one should be merging straight into main as far as I can tell

I do also have a bot commenting the min set of reviewers needed for a PR (code <https://github.com/rdelfin/min-review-bot|here>) and it seems to agree that the PR is good to merge

No worries, thanks!
We do have really weird owners :sweat_smile:

Hi! I think this issue is back/still there <@U0486U7UUF3>: <https://app.graphite.dev/github/pr/wayveai/WayveCode/34169>

I see this at the top:

also can you leave the pr as is for a little bit

I'll leave it as is and hope CI doesn't push a commit to it

Hi there! What do you mean by not being able to activate it? Do you see error toasts?

no. If my changes pass the build requirements but doesn't have a review from the reviews I requested, it won't let me hit 'merge when ready', but there is a big `Merge` button

Is it possible that the PR doesn't see the review I requested as a requirement?

Does your repo respect review-required branch protection rules or any sort of codeowner rules?

Basically the merge when ready toggle disappears when we determine that the PR is fully mergeable

the toggle also doesn't disappear and perhaps it should, but fair enough

Ah sorry my bad, I meant that it's disabled

So that's probably why you aren't able to toggle it, since the PR is technically fully mergeable

CleanShot 2023-06-23 at 21.50.40@2x.png

Context - I exclusively use graphite CLI (no git) and recently I have been getting this message when I commit:
```See "git help gc" for manual housekeeping.
warning: The last gc run reported the following. Please correct the root cause
and remove .git/gc.log
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to remove them.```
I ignored it while I was trying to get some work out. This morning, I was working on a stack, submitted it (`gt ss` ) and after that I tried to switch to a different branch (`gt bco` ) but none of the branches I'd created in the approx the last week showed in `gt bco` . `gt bco branch_name` returned `ERROR: Could not find branch branch_name`.

The ones I had pushed I could recover with `gt downstack get branch_name` .

The ones i hadn't yet pushed to remote I could see in `git branch` but haven't been able to get them into graphite, Even after pushing to remote git, `gt branch track` returns `ERROR: Could not find branch branch_name.` even though I can checkout the branch with git with `git checkout branch_name`

ah that's so weird, sorry this is happening! will be a question for <@U02RREE9GKH> when he's back, sounds like the graphite metadata in your repo might have gotten messed up

did you run `git prune`? sounds like your git garbage collection is behind

as for why your branches became untracked, i don't believe it's directly related to the garbage collection issue, but you should be able to fix them with `gt branch track`/`gt downstack track`

Sorry, totally missed these replies! Looking at the error message it does seem like something is wrong with my garbage collection. I have now run git prune, but I hadn't before this. Seems like probably something off with my local setup! Everything has been fine since this one-off issue. Will let you know if happens again!

The strange part that I thought was worth mentioning was when `gt branch track` returned `ERROR: Could not find branch branch_name.` even though I can checkout the branch with git with `git checkout branch_name` .

Hi <@U03EN73V2DP>! How large is the diff you are trying to summarize?
Unfortunately for larger diffs we are limited by OpenAI’s API, and so our summarize feature will not work (but you should’ve seen an error message for this)

<https://graphite-community.slack.com/archives/C02DRNRA9RA/p1687462856156399?thread_ts=1687462856.156399&amp;cid=C02DRNRA9RA|https://graphite-community.slack.com/archives/C02DRNRA9RA/p1687462856156399?thread_ts=1687462856.156399&amp;cid=C02DRNRA9RA>

Sorry you ran into this! We’re actively working on adding a setting for these additional checks :heavy_check_mark:

Hi <@U05E6DVAUCW> - we had a bug while working on our feature gates. This should be resolved ASAP - <@U02DGG322G5>.

Please look out for announcements about our new paid plan shortly!

Hi <@U05E6DVAUCW>, what repo are you submitting it to? Is it an org repo or a personal repo?

Ah, <@U05E6DVAUCW>, I found the bug - so sorry abou that - rolling out a fix!

Sorry for the delay, it was an org repo indeed.
I guess we’ll run into the same issue with the release of tiers, but at least we’ll be able to upgrade in order to bypass the stack limit.

Hi there! Thanks for pointing this out, we'll see what's going on here and get back to you!

Please let me know if you guys need any more information to debug

Hey Tom! Thanks for raising this, we'll take note of it and see if we can push a fix soon.

Hi there! So sorry this is happening to you - <@U04HQKF7TSN> are you able to take a look here?

`erikras`

Going to bed now, but let me know what you can figure out.

So I see a bunch of bad credentials errors, which means that there is an issue with auth. Could you try the following:
1. Go to <http://app.graphite.dev/settings|app.graphite.dev/settings>
2. Sync permissions
3. Try and switcah to GitHub App if you're using OAuth or PAT
4. Try syncing permissions again
5. If none of these steps work, I will try and reset your Graphite user entity which usually fixes these things

<@U04HQKF7TSN> I’ve done all those things a couple of times. No luck. Can you hard reset me? :pray:

I’ve revoked the GH OAuth app and re-given permissions. My repo already has the Graphite Github App installed (it comments on our PRs). I’ve blown away all cookies and app data for <http://graphite.dev|graphite.dev> in my browser.

Still not working. I can see activity on my PRs in the notifications, but they won’t show up on my dashboard.

Screenshot 2023-07-12 at 1.01.43 PM.png

Figured it out! This was very non-obvious from the UI.

Oh that was so silly! Sorry about that. We'll look into making this more obvious.

Is the standard recommendation to disconnect the bot and re-add it?

It wasn't a problem for me this time, but if people are relying on it as their primary notification source, like I do, this kind of silent failure could cause them to miss things. Maybe there's a way the bot can let us know if auth tokens expire (or whatever happened here).

Hi there! Sorry about the silence Ben :((
<@U04AP0M9AES> might know what's going on here

hey! really sorry you’re running into this — let me see what i can do here!

ok so it looks like we’re seeing `channel_not_found` errors from slack… before you try re-authing the bot, could you see if any of your slack settings have changed recently? maybe someone re-authed the app recently?

I'm not a slack admin here, but I don't know of anything that's changed recently

no worries! that means it’s probably something on our end :slightly_smiling_face:

ooc have you tried re-authing? im curious to see if this goes away or not

also are other users in your org still receiving notifications?

and no, I haven't tried reauthing yet cause I want to keep the broken state in case it's helpful for y'all :smile:

Looks like it's not just me... at least one other engineer, probably everyone who uses it

absolutely, LMK if there's anything else I can poke at

im just stepping out for now, but I'll be back online later tonight to look into what happened to your org's install 

No problem, I'm not blocked :slightly_smiling_face:

leaving this here for posterity!
<https://graphite-community.slack.com/archives/C02DRNRA9RA/p1688055341286599>

Hi Sasha, our latency metrics are looking normal on our side. Anything in particular being slow for you?

entire team is having trouble loading prs, dashboard, etc

In terms of core behavior, I'd expect either for "Auto Merge" to have not merged my PR for me, or for the Merge button to not be disabled. Smaller thing is that the UI didn't represent the status very well until I reloaded.

Hey ben! Thanks for the feedback - we'll see what's going on here

Seems to load once I toggle my user agent ... and fwiw, I'm seeing a bunch of CORS errors

You're not weird, you're a <https://www.theverge.com/2016/9/7/12838024/apple-iphone-7-plus-headphone-jack-removal-courage|courageous> person who thinks different :apple:

Hmm thanks for the screenshots!
<@U02DGG36CSH> any suggestions here?

Recently lost local git changes. Had to start over. Cloned repo, `git checkout` the various branches, restacked them, then `gt branch track` to get them back into graphite.

But now I’m getting those `500` errors when I try to submit the stack

the first PR that needs updating will in fact get updated, as in, my workaround is to re-run `gt ss` until all PRs are updated

```❯ gt --version
0.20.21

❯ npm --version
9.7.2```

I just found the `--debug` flag
```📨 Pushing to remote and creating/updating PRs...
2023-06-27T20:03:01.453Z: Persisting cache...
ERROR: Unexpected server response (500).

Response: {
  "_response": {}
}
2023-06-27T20:03:01.480Z: ExitFailed: Unexpected server response (500).

Response: {
  "_response": {}
}
    at requestServerToSubmitPRs (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/actions/submit/submit_prs.js:73:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async submitPullRequest (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/actions/submit/submit_prs.js:13:17)
    at async submitAction (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/actions/submit/submit_action.js:78:9)
    at async Object.run (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/commands/stack-commands/submit.js:16:9)
    at async graphiteHelper (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:96:9)
    at async /usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:71:20
    at async Tracer.span (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/utils/tracer.js:91:22)
    at async graphiteInternal (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:55:9)
    at async Object.handler (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/commands/stack-commands/submit.js:15:5)```


I had to use a different auth token, of course.

retrying was a workaround for existing PRs, but I can’t submit new ones
this is now a blocker for me

Not sure there is anything new in the stacktrace, but this is what I get when creating a new PR via `gt ss`:
```2023-06-30T13:58:11.832Z: ExitFailed: Unexpected server response (500).

Response: {
  "_response": {}
}
    at requestServerToSubmitPRs (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/actions/submit/submit_prs.js:73:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async submitPullRequest (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/actions/submit/submit_prs.js:13:17)
    at async submitAction (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/actions/submit/submit_action.js:78:9)
    at async Object.run (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/commands/stack-commands/submit.js:16:9)
    at async graphiteHelper (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:96:9)
    at async /usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:71:20
    at async Tracer.span (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/utils/tracer.js:91:22)
    at async graphiteInternal (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:55:9)
    at async Object.handler (/usr/local/volta/tools/image/packages/@withgraphite/graphite-cli/lib/node_modules/@withgraphite/graphite-cli/dist/src/commands/stack-commands/submit.js:15:5)```

well, `gt ss` works again, no more
```ERROR: Unexpected server response (500).

Response: {
  "_response": {}
}```

Hmm weird. Did you do anything on your part? We'll investigate to see if there was something malicious happening here

I haven’t changed anything. Same host on which gt is installed. Same auth token. Same PRs even :shrug:

We faced a similar issue like 2 hours ago.

Upgrading the graphite CLI and re-generating the token using `<https://app.graphite.dev/activate>` resolved the issue

ah, some additional helpful context: node version is 20.3.1, npm version is 9.6.7, normal git operations still work (git pull/fetch etc.), and passthrough from graphite to git seems to work fine (gt push, etc.)

Thanks for the info! <@U02RREE9GKH> might know what's going on here

this is still happening for me :disappointed:

Hey <@U05F8PBFEQ0>! Sorry about that - we'll take a look and get back to you!

hello. on graphite latest and this is still happening to me :disappointed:. really unfortunate experience here - is `gt repo sync` not a recommended workflow?

although the latest stacktrace seems to be more helpful:

```❯ gt rs --debug
2023-07-13T17:08:27.790Z: Reading cache seed data...
2023-07-13T17:08:27.809Z: Loading cache...
2023-07-13T17:08:27.809Z: Building cache from disk...
2023-07-13T17:08:27.822Z: Validating branches...
2023-07-13T17:08:27.822Z: trunk: develop
2023-07-13T17:08:27.834Z: validated: sm/remove-cluster-meta
2023-07-13T17:08:27.840Z: validated: sm/helm-migration
🌲 Pulling develop from remote...
develop is up to date.
2023-07-13T17:08:29.382Z: Clearing persisted cache...
2023-07-13T17:08:29.394Z: Failed to persist Graphite cache
ERROR: fetch failed
2023-07-13T17:08:29.412Z: TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async getPrInfoForBranches (/opt/homebrew/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/api/pr_info.js:20:22)
    at async syncPrInfo (/opt/homebrew/lib/node_modules/@withgraphite/graphite-cli/dist/src/actions/sync_pr_info.js:10:24)
    at async syncAction (/opt/homebrew/lib/node_modules/@withgraphite/graphite-cli/dist/src/actions/sync/sync.js:22:5)
    at async Object.run (/opt/homebrew/lib/node_modules/@withgraphite/graphite-cli/dist/src/commands/repo-commands/repo_sync.js:49:9)
    at async graphiteHelper (/opt/homebrew/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:97:9)
    at async /opt/homebrew/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:72:20
    at async Tracer.span (/opt/homebrew/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/utils/tracer.js:91:22)
    at async graphiteInternal (/opt/homebrew/lib/node_modules/@withgraphite/graphite-cli/dist/src/lib/runner.js:55:9)```

fwiw I’m not a user of the graphite UI in this context, just the CLI

let me upgrade graphite again and double-check :slightly_smiling_face:

```🌲 Pulling develop from remote...
develop is up to date.
2023-07-19T14:37:53.362Z: Clearing persisted cache...
2023-07-19T14:37:53.369Z: Failed to persist Graphite cache
ERROR: fetch failed
2023-07-19T14:37:53.379Z: TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)```

although the debug output is more helpful this time - something abt bad parents? although this happens on all of my repos though, so idk if it’s just a repo-specific problem

Weird, thanks for the flag! <@U02DGG36CSH> anything you touched with the CLI recently?

```2023-07-19T14:37:48.232Z: bad parent name: sm/no-op-fix
	missing
2023-07-19T14:37:48.241Z: validated: sm/v2-read
2023-07-19T14:37:48.241Z: invalid parent: sm/write-v2
2023-07-19T14:37:48.247Z: validated: sm/v2-write
🌲 Pulling develop from remote...
develop is up to date.
2023-07-19T14:37:53.362Z: Clearing persisted cache...
2023-07-19T14:37:53.369Z: Failed to persist Graphite cache
ERROR: fetch failed
2023-07-19T14:37:53.379Z: TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)```

Hmm I haven’t. I think <@U02RREE9GKH> would be the right person for the job here!

Hmm this should definitely not be the case. Are you seeing the bolt organization/repos on your repo selector in the left panel of your PR inbox?

No. Just activity from its repos. If I click into a bolt pr I can see pr description but not the contents of the pr

Agh sorry about that and thanks for bringing it up - we're looking into it right away! What's your github handle?

This should be resolved!! Cc <@U02DGG36CSH> 

Hi everyone, due to a bug on our end the Graphite Slack bot lost permission to send Slack notifications to folks in a handful of organizations over the last month — we’ve since implemented a fix, but you may need to re-authenticate the Graphite Slack app (by removing and re-adding it to your workspace in <https://app.graphite.dev/settings/notifications?org=withgraphite|settings>) in order for us to send you messages again.

We’re really sorry about the disruption and want to make sure that everyone’s notifications are working as expected. Please feel free to let me know if you have any questions or if something isn’t working right after re-authing the app!
Slack Conversation

Thanks for the report! <@U04AP0M9AES> for vis