Graphite Community

Screenshot 2023-07-19 at 2.32.53 PM.png

Hi there! Is the merge button gone altogether, or just the ability to merge as a stack? Are the PRs appearing as disjoint in the dashboard (i.e. does the dashboard not think they're a stack)?

that’s correct, they’re all appearing but they don’t seem to be recognized as a stack!

Gotcha - has the name of your repository changed recently?

we updated the name in the last few weeks

Ah, make sure you update the name of your repo using `gt repo name --set` to match what's on GitHub, this should fix it!

ah thank you! i assume i need to resubmit the stack after i do that?

awesome, thank you <@U04K5N14V9B>! appreciate the speedy response

confirming that worked! thanks again <@U04K5N14V9B>

image.png

Omg thanks for flagging - we'll put out a fix right away!

hmm, i'll see what the issue is here! thanks for reporting!

`gt downstack track` should work in the meantime

confirmed `gt downstack track` is there and works

CleanShot 2023-07-20 at 15.00.02@2x.png

hey! sorry you’re running into this — a fix is rolling out for it right now!

I also tried untracking the bad branch, which also gives error 128. I tried removing .graphite_cache_persist as well and it still gives this error

`gt dev cache --clear` gives me `ConcurrentExecutionError: Cannot run more than one Graphite process at once.`

Hi there! Are you seeing this issue when using gt in other repositories?

Hm weird - we'll take a look. Thanks for flagging!

Any idea how I can fix this? Will I lose my work if I make more changes now?

Hmm I'm a little confused here - notifs are visible but you're not receiving them? Have you tried re-authing the Slack app? 

<https://graphite.dev/docs/slack#re-installing-the-integration-on-important-updates|https://graphite.dev/docs/slack#re-installing-the-integration-on-important-updates>

aye correct characterization! will try that!

i have tried re-authing the slack app, but this still repros reliably. I'll also reach out to slack

Weird! Let me know what Slack says, or I'll have someone look into it on our end

no word back from slack and still repros reliably for me.

MacOS gives me system notifications from Graphite (via Slack), but the leftnav in Slack doesn't have the "(3)" indicator :sob:

oh hmm just got my first indicator! :thinking_face:

Strange - let me have someone look into this for you!

CleanShot 2023-07-21 at 09.42.25.mp4

Thanks for flagging! Creating a ticket :slightly_smiling_face:

Screen Shot 2023-07-21 at 7.06.46 PM.png

Screen Shot 2023-07-21 at 7.07.09 PM.png

Maybe an instance of <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1685648304871279?thread_ts=1685648304.871279&amp;cid=C02DRNRA9RA|https://graphite-community.slack.com/archives/C02DRNRA9RA/p1685648304871279?thread_ts=1685648304.871279&amp;cid=C02DRNRA9RA>?

I’ll take a look today, thanks for the report!

thanks <@U047KHH8JH3>! Please keep me updated. this bit us again today

Hi Declan - this is supposed to be fixed now but we know there might be rough edges, so please let us know if you see any more bugs like this!

```ERROR: Cannot run more than one Graphite process at once.```

what does the output look like with `—-debug`

```2023-07-24T14:18:23.595Z: Forking: background upgrade-prompt...
2023-07-24T14:18:23.603Z: Forked and unrefed: background upgrade-prompt
2023-07-24T14:18:23.678Z: Reading cache seed data...
2023-07-24T14:18:23.720Z: Loading cache...
2023-07-24T14:18:23.731Z: Acquiring cache lock...
ERROR: Cannot run more than one Graphite process at once.
2023-07-24T14:18:23.784Z: ConcurrentExecutionError: Cannot run more than one Graphite process at once.
    at Object.lock (/snapshot/monologue/apps/public/cli/dist/graphite.js)
    at /snapshot/monologue/apps/public/cli/dist/graphite.js
    at Generator.next (&lt;anonymous&gt;)
    at /snapshot/monologue/apps/public/cli/dist/graphite.js
    at new Promise (&lt;anonymous&gt;)
    at An (/snapshot/monologue/apps/public/cli/dist/graphite.js)
    at /snapshot/monologue/apps/public/cli/dist/graphite.js
    at /snapshot/monologue/apps/public/cli/dist/graphite.js
    at Generator.next (&lt;anonymous&gt;)
    at /snapshot/monologue/apps/public/cli/dist/graphite.js
2023-07-24T14:18:23.785Z: Forking: background post-traces...
2023-07-24T14:18:23.793Z: Forked: background post-traces
2023-07-24T14:18:23.793Z: Flushing trace...
2023-07-24T14:18:23.795Z: Sent trace to child...
2023-07-24T14:18:23.795Z: Done
2023-07-24T14:18:24.001Z: Child disconnected```

Try `rm .git/.graphite_cache_lock` and then run the command with `--debug` again

That fixed the graphite process issue, and submitting a stack works this time around

I think it was just a temporary network issue or something, which happens — real issue is that caused the lock, and it’s not clear how to clear the lock (I looked in the docs)

UNCAUGHT EXCEPTION: request to <https://api.graphite.dev/v1/graphite/pull-requests> failed, reason: getaddrinfo ENOTFOUND <http://api.graphite.dev|api.graphite.dev>
UNCAUGHT EXCEPTION: FetchError: request to <https://api.graphite.dev/v1/graphite/pull-requests> failed, reason: getaddrinfo ENOTFOUND <http://api.graphite.dev|api.graphite.dev>

Yeah, as you caught, the key issue is that we only unlock when we catch the exception (the "uncaught exception" should never be hit) — which `gt` command is causing the uncaught exceptions?

also I’m getting that network error very often

``` ping api.graphite.dev
PING api.graphite.dev (34.223.167.44): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C```

```% ping <http://google.com|google.com>
PING <http://google.com|google.com> (142.251.143.78): 56 data bytes
64 bytes from 142.251.143.78: icmp_seq=0 ttl=116 time=25.209 ms
64 bytes from 142.251.143.78: icmp_seq=1 ttl=116 time=26.664 ms
64 bytes from 142.251.143.78: icmp_seq=2 ttl=116 time=25.851 ms```

I can’t access <http://app.graphite.dev|app.graphite.dev> either

what do you get for
```dig api.graphite.dev```

if i do this, i get a 404 page (which is correct i believe)
```╰ curl -is <https://api.graphite.dev/>
HTTP/2 404
date: Mon, 24 Jul 2023 18:26:28 GMT
content-type: text/html; charset=utf-8
content-length: 139
x-powered-by: Express
x-graphite-request-id: a573b7bf-4781-4b35-9d2e-ee9034d87ddb
vary: Origin
access-control-allow-credentials: true
content-security-policy: default-src 'none'
x-content-type-options: nosniff

<!DOCTYPE html>
&lt;html lang="en"&gt;
&lt;head&gt;
&lt;meta charset="utf-8"&gt;
&lt;title&gt;Error&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;pre&gt;Cannot GET /&lt;/pre&gt;
&lt;/body&gt;
&lt;/html&gt;```

our Express server is responding at least. what do you get for that?
i also see that `ping <http://api.graphite.dev|api.graphite.dev>` doesn't work, but we might just drop ping packets on the floor

I’d dropped off yesterday. I’ll report back if I encounter these issues again today and see if I can get the details you’re asking for at that time

First command I ran today…
```% gt rs
🌲 Pulling master from remote...
From <http://github.com|github.com>:....
 * branch              master     -&gt; FETCH_HEAD
master fast-forwarded to b2567d7fadda2396bcbb907bb60129f5f8a3534f.

tip: You can skip pulling trunk with the `--no-pull` flag.
Feeling expert? `gt user tips --disable`

ERROR: request to <https://api.graphite.dev/v1/graphite/pull-requests> failed, reason: getaddrinfo ENOTFOUND api.graphite.dev```

```; &lt;&lt;&gt;&gt; DiG 9.10.6 &lt;&lt;&gt;&gt; api.graphite.dev
;; global options: +cmd
;; Got answer:
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 9601
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;api.graphite.dev.		IN	A

;; ANSWER SECTION:
api.graphite.dev.	60	IN	A	34.223.167.44
api.graphite.dev.	60	IN	A	52.36.59.207
api.graphite.dev.	60	IN	A	34.216.49.219

;; Query time: 61 msec
;; SERVER: 10.128.128.128#53(10.128.128.128)
;; WHEN: Tue Jul 25 13:17:56 CEST 2023
;; MSG SIZE  rcvd: 93```

Worked a second time. When I repro next I’ll try the curl

if you do this
```╰ whois graphite.dev | rg "Name Server"
Name Server: <http://ns-1506.awsdns-60.org|ns-1506.awsdns-60.org>
Name Server: <http://ns-1950.awsdns-51.co.uk|ns-1950.awsdns-51.co.uk>
Name Server: <http://ns-419.awsdns-52.com|ns-419.awsdns-52.com>
Name Server: <http://ns-578.awsdns-08.net|ns-578.awsdns-08.net>
Name Server: <http://ns-1506.awsdns-60.org|ns-1506.awsdns-60.org>
Name Server: <http://ns-1950.awsdns-51.co.uk|ns-1950.awsdns-51.co.uk>
Name Server: <http://ns-419.awsdns-52.com|ns-419.awsdns-52.com>
Name Server: <http://ns-578.awsdns-08.net|ns-578.awsdns-08.net>```

i get this
```╰ dig api.graphite.dev @ns-1506.awsdns-60.org

; &lt;&lt;&gt;&gt; DiG 9.10.6 &lt;&lt;&gt;&gt; api.graphite.dev @ns-1506.awsdns-60.org
;; global options: +cmd
;; Got answer:
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 23878
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;api.graphite.dev.              IN      A

;; ANSWER SECTION:
api.graphite.dev.       60      IN      A       52.36.59.207
api.graphite.dev.       60      IN      A       34.223.167.44
api.graphite.dev.       60      IN      A       34.216.49.219

;; AUTHORITY SECTION:
graphite.dev.           180     IN      NS      <http://ns-1506.awsdns-60.org|ns-1506.awsdns-60.org>.
graphite.dev.           180     IN      NS      <http://ns-1950.awsdns-51.co.uk|ns-1950.awsdns-51.co.uk>.
graphite.dev.           180     IN      NS      <http://ns-419.awsdns-52.com|ns-419.awsdns-52.com>.
graphite.dev.           180     IN      NS      ns-578.awsdns-08.net.```

which more or less matches your DNS results

do you have a funny DNS setup where you're at? a pihole perhaps?

I don’t think there’s a funny DNS setup. I haven’t run into this since, will check the above if/when I do

also running into `cannot run more than one graphite process at once`, seems like it occurs when graphite is unable to commit to github due to bad wifi signal

Yeah, error recovery from network issues needs to be better. And it would be helpful if there was more public information on how to fix an invalid “more than one graphite process”

&gt; more than one graphite process
this bug is fixed in the most recent version

Screenshot 2023-07-24 at 7.44.05 AM.png

If you `gt repo sync --restack` and resubmit, these conflicts will go away :slightly_smiling_face:

so what is the point of merging from graphite's ui instead of directly from github if we have to execute this command manually anyways?

merging a single pr from our UI is equivalent to from GitHub's — merging multiple PRs in a stack in a single operation is what we handle for you

seems we are running into some bug. our stacked PRs suddenly disappeared from the graphite PR ui ...

clicking on the menu items on the left does nothing

I think that clicking the names of the sections isn't doing anything because those sections are already visible so there is nothing to scroll to.  We'll take a look at why your PRs might not be showing up in the inbox though,

another question: if i need to modify one  of the prs in the middle of the stack, do i need to then run `gt repo sync --restack` to let the child branches know about the modifications?

`gt commit amend`/`gt commit create` automatically restack the dependent branches locally, you'll need to push the updated branches with `gt stack submit` though

what if someone on the team accidentally used `git` instead of `gt` for some of the commits and pushed. how do they then get everything back in sync with graphite in that case?

Hey <@U03CW1KTA1L> what is your GitHub handle? I can investigate why you are seeing weirdness on the Review Queue sections.

And you are still seeing PRs missing from your Review Queue? Could you DM me a PR you don't see and what section you expect to see it in?

Screenshot 2023-08-04 at 9.32.35 AM.png

the PR on the left in github is nowhere to be found in graphite

The PR is in draft status. Do you want to see draft PRs from others on the review queue?

well the 'drafts' section in the Graphite window shows 0. i do want to see the PRs..

I see. The "Drafts" section only shows PRs you have authored as configured right now.

You can update the settings by clicking the gear icon, and remove the filter where it looks for just your PRs.

For example, these are the settings on my "Drafts" section. I can hit the `X` button next to the "Author's username is aryamannaik" filter, and then it will show me draft PRs from all authors.

This is super weird, have you tried doing `gt upstack onto branch_just_below` while having `top_branch` checked out?

Regardless, this sounds like weird behavior - looping <@U02RREE9GKH> in

<@U04K5N14V9B> yeah, and what I get is `ERROR: Cannot perform this operation on untracked branch top_of_stack.`

Ok, so first I `gt branch track` and then try `upstack onto` again, and I get a huge number of conflicts.

So after battling my way through all of the conflicts, now it looks like it's back in a good state

But I have to be honest now I'm scared to continue to stack PRs on top of this one

Sorry about that! Don't immediately know what happened here but we'll take a look and get back to you

CleanShot 2023-07-24 at 20.44.57.png

CleanShot 2023-07-24 at 20.48.50.png

it happens occasionally. i have to clear my local storage and sign in again to resolve it.

CleanShot 2023-07-31 at 05.55.17@2x.png

this just happened again. this is my browser console.

Ooh thanks for catching it! Let me run this by the team

`MAIN` is all caps, which I'm guessing isn't intended? If for emphasis, maybe bold

Instead of "All commits in this PR", maybe "All commits in each PR". At first I thought this was merging all the commits in all of these down into one commit.

Thanks! Will create tickets for these :slightly_smiling_face:

If it's not recommended though, I'd consider putting it behind an advanced menu or collapse component or something. Or if it's deselected, be louder about how the user is doing a not-recommended thing. It's very easy to click accidentally, even with the tooltip situation fixed.

Ooh thanks as usual for all the detailed feedback here, Ben! I think we're going to explore some changes to the UI in this modal in general - but noted on the tooltip bug! Creating a ticket

I tried to type `should this also be in /fonts/?` and the `/` triggered the meme dialog. I pressed escape to dismiss it and ended up in this situation. :open_mouth: z-indices are hard!

Thank you <@U05597DUYDD> for adding focus rings to those buttons btw!

i think we had a separate zindexing bug yesterday

i filed this one under our escape key main issue

Have you tried <https://graphite.dev/docs/graphite-cheatsheet#troubleshooting-the-cli>

```core ❯ gt repo init --reset &amp;&amp; gt dev cache --clear     
ERROR: Cannot run more than one Graphite process at once.```

`rm .git/.graphite_cache_lock` should fix, sorry about that!

new release coming asap that will fix the issue

Though members of the repo were consistently able to write comments on PRs using and other integrations (e.g. Vercel) didn't have problems with writing automated comments.

Hmm thanks for flagging, are you able to point me to a specific PR where this is happening?

Hey! <https://github.com/isometric/isometric/pull/3732> is an example one where we missed the Graphite comment (it's merged now)

And here are some PRs that are still open. They are part of a stack, but:

• <https://github.com/isometric/isometric/pull/3747> – doesn't have the stack comment at all
• <https://github.com/isometric/isometric/pull/3746> – has just itself in the stack comment

Thanks for flagging these! We'll take a look - this shouldn't be the case!

We're doing some digging and noticed that we're failing to find a base reference for your stacks and this issue is super localized (to mostly your org `isometric` and around 3 others) which is really strange. I'll keep you updated on what the issue here could be!

So, apparently we had a bug in our `.git-blame-ignore-revs` file. Missing `#` before a comment broke some of GitHub's API. :upside_down_face:

We're not sure if all functionality will be back, but Occam's Razor would say yes! I'll keep you posted if something is still broken on our end over the next couple of days.

Oh interesting - thanks for the context! Let me know if you're still running into issues but we'll keep this in mind for the future

Hi, which version of the CLi is this with? we just pushed a version v0.21.1 that replaces the executable with webpacked `.js` for now while we work on building binaries for more architectures

Oops, actually this version isn't out yet, but will be shortly.

You can fix this yourself until then (should be under an hour) by adjusting the hard link locally — if you look in the folder where the `gt` executable lives, it's currently a hard link to `gt-linux`, you can change it to be a hard link to `graphite.js` and that should fix it

Just updated to 0.21.3 and it seems to be working, thanks!

Hi there! Sorry this is happening - filing a ticket for this and we'll look into it!

Sorry you're running into this! Filed a task for us to look into it :slightly_smiling_face:

Here's a screenshot from my colleague (new to Graphite, should have defaults)

Definitely not expected. Could you share a PR org/repo/number where that happened? I can take a look

PR #5494 is by me, and has arapoport3 as a direct reviewer

<https://github.com/archiveresale/archive/pull/5494|archiveresale>

<https://github.com/archiveresale/archive/pull/5494>

Thanks. Let me take a look. It is possible it is related to this GitHub PR <https://www.githubstatus.com/|incident>, and we aren't getting all the data back from the GitHub API.

I had this issue several hours ago (it might have been late last night PT actually), before the official start time of the issue.

Looks like this just started though, so if you have been experiencing this for a few days it is more likely on our side.

but maybe service was degraded before Github called a sev :woman-shrugging:

It looks like 5494 was approved by `arapoport3` a few minutes ago, and I see it correctly in their `Waiting for author` section. Is there another example I could use to debug? Something that you expect to see in `Needs your review` but isn't there.

oh sorry, I went to it directly via URL and approved (I'm `arapoport3` ), but it wasn't showing up before in the `Needs your review`

No worries, could you let me know if this happens again? I'll jump on it immediately and debug. I'm unable to reproduce it for myself unfortunately.

Thanks so much to the both of you for reporting these things!

<@U04HQKF7TSN> I just added <@U05JVETSFUJ> to the PR `archiveresale/archive/5495`. Not sure if it's showing up properly for her, but it might repro the issue...

when i review a PR and "just comment", should it then show up in the `waiting for author` section? if so, seems like there may be a bug there with `archiveresale/archive/5495`

Looks like we're missing your review in our data store, resulting in the filters not working correctly. Trying to figure out why your review is missing in our store.

We've narrowed down, thinking about how to fix. Will keep you all updated. Thanks for the report@

Ok this should be fixed now, we got into some really weird state with our cache having the data, but our DB not having it, resulting in us never writing to the DB. This should be fixed for the PR in question now, but we'll investigate why this happened in the first place. Based on the logs it looks like 5495 should now be in `arapoport3`'s "Waiting for author" section.

i see it there now! thanks for the quick fix!

There was a GitHub incident that was affecting merges (<https://githubstatus.com/>). Looks like it just now resolved. We had a banner up to notify users about this as of 30 minutes ago, did you try and merge before that?

Or else there might be a problem with our banners :disappointed:

Hmm, I have to admit I might have dismissed the banner without paying attention :sweat_smile: But it's still happening to me this morning, and the status page seems to indicate everything's good on Github's end?

Just when i thought I fixed all the 404s, thanks for flagging Kenny!

This isn't something I remember as being as disruptive... it feels like scroll jank/jumping got worse overall recently

Hmm, we might have had a regression here — filed a task for us to look into this! Do you mind sharing the PR this was on for ease of reproduction?

mm, thanks! filing a task to address this — we should only create an empty branch if no commit message is passed in

I think that's exactly the best approach. Thanks <@U02RREE9GKH>!

Other team members have reported hitting this also

ok apparently switching auth methods to oauth works. we were using PATs previously

Thanks for flagging - we'll look into this! Are you guys able to use GitHub App auth?

(Also we're updating the settings UI here to make switching/knowing what auth method you're using better)

<https://graphite.dev/docs/authenticating-with-github#authenticating-with-github-app-strongly-recommended>

Installing the Graphite GitHub App is probably the best way to interact with Graphite (especially if you're on Graphite Team)

If you go to your account settings and click `Try switching to repo access using GitHub App`, you should be prompted to install the app!

screenshot.jpg

i just tried installing now and it seems to imply that doing so would mean i have to re-request repo permissions?

all my repos where i’ve been working on have the “request” chip next to them in the dropdown

Ah yeah I believe that's the case since the OAuth App is separate from the GitHub App - cc <@U02DGG36CSH> here

Yes, if you have the ability to specify repositories within your org, you're on the correct method (GitHub App) and not the incorrect one (OAuth App)

hey yeah - so circling back here, it was an error on our part. Our purchaser isn’t technical and wasn’t familiar with the flow so unintentionally restricted our access when we signed up for the paid plan. Would be helpful probably to call this out in your upsell process!

Glad you were able to resolve, and yeah, we're definitely working on improving this!

had a minor panic attack yesterday when i thought i’d have to actually use git for once

We have fix for this that should be out later today!

hey! we had the team plan locked to US-only while we sorted out the tax implications of accepting international payments — all of that is finished now so you should be able to checkout with your UK address!

feel free to lmk if you run into any issues here :slightly_smiling_face: