Graphite Community

image.png

I’m seeing the same thing on a PR thats `-13/+6`. The PR also only had 2 files changed and both files were small in absolute size too (98 lines and 36 lines total).

<@U03FNT1FLP5> and <@U02NXEUP3G8> can you DM me the URL's of the PR's you're seeing this for? I can take a look. -13/+6 is particularly small, I wouldn't expect it to fail for that, so might be something else going on

update: root cause was with the new OpenAI model, I'm reverting to the old one to fix this. fix will be live later today.

+1, when I do `gt stack submit` it's hanging and sometimes eventually errors out with that same message

<https://graphite-community.slack.com/archives/C02DRNL3HQU/p1677793520336649>

Just to follow up here - we just saw a 15 minute long spike in 500's from our AWS application load balancers. Unclear why at the moment, but we believe our servers were healthy the whole time :thinking_face:

added an integration to this channel: <https://graphite-community.slack.com/services/B04S7PVLKSQ|Instatus>

IIUC, it's when the cache disagrees with what the latest version is, and then things catch up. cc <@U02RREE9GKH> who understands this better

This seems somewhat related to the issue I reported here: <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1677706274719979>

Cc <@U02RREE9GKH> is this the same issue you’re currently fixing?

I then go back to my local and do `gt repo sync` `gt stack restack` `gt stack submit` and it works beautifully (gt stack restack is an awesome command!)

I have a feeling this might be a hairy bug, can imagine there’s a lot happening in the backend to get this to work!

Yep — working on this bug today :slightly_smiling_face:

I think just squash and merge? whichever the default was

Take a look at these docs if you haven't already as well. <https://graphite.dev/docs/slack-integration|link>

Same here, have also not been able to get notifications working consistently. Only have seen one come through and it stopped working after that

hey <@U03RGJEDWH5> and <@U04RXRV9K35>! from looking at our logs, it seems like we’re having issues fetching the latest state of PRs in each of your repos from GitHub — could you check out your GitHub access in settings and ensure that you’ve granted Graphite access to the scopes listed <https://graphite.dev/docs/privacy-and-security|here>?

It _looks_ correctly set up in the UI, we're using the Github App integration

Although I will say the github app setup is a little wonky because everyone we onboard has issues getting the repos to show up

Just verified that things look right on my end, we have the oauth integration explicitly disabled, and the app integration enabled with one repo granted. Let me know if we can help debug this at all! :slightly_smiling_face:

thanks for checking on that! i’ve got a lead on a potential issue and am testing out a fix — will let you know tomorrow how that goes and if you can help with anything!

sweet! those came from my testing — seems like the fix works (it also seems to be working for <@U04RXRV9K35> too based on what i can tell) so we’ll go ahead and land it :smile:

this should hopefully resolve the entire class of ‘things seem stale on Graphite’ issues that y’all were running into!

the tl;dr is that our background syncing engine which keeps your Graphite dashboard up to date (and sends notifs) wasn’t communicating with GitHub correctly under certain edge cases — hopefully our fix should get things up and running for you both, and the rest of your teams :slightly_smiling_face:

I'm now receiving notifs, but they aren't real time! attached is a 45min delay example

unfortunately we caused an outage on our sync engine earlier today (which has since been resolved) and our systems are currently catching up, which results in the delayed notifications that you’re seeing

we’re sorry your workflow was impacted and are working on improving our outage processes and communication going forward — in the future you’ll be able to see these kinds of incidents represented on our <https://status.graphite.dev/|status page>!

Hi! These settings are not meant to be available right now! Sorry for the confusion

So we’re not meant to be able to use labels to trigger external merge queues anymore? That was working great for me, do you plan to support that again in the future?

My understanding is that labels to trigger merge queues hasn't been working since the early fall and we removed the settings page because of it

The new settings page you're seeing is for the Graphite merge queue we're working on, but is meant to be feature flagged off for now, cc <@U02E95J4648>

do you have any examples of PRs that were recently successfully merged via Graphite merge + label?

I’m pretty happy with kodiak’s merge queue behavior as they support fast forward only rebase/merge. And it does seem to still be working for me using the old rules settings, I can just only use it on a single repo at a time. Will grab the PR. 

Maybe I’m getting ahead of myself since it was only a single PR stack but this one successfully applied the label &amp; Kodiak picked it up to merge: <https://app.graphite.dev/github/pr/codeconfab/constellaryhq/13/More-next-auth-cleanup|https://app.graphite.dev/github/pr/codeconfab/constellaryhq/13/More-next-auth-cleanup>

<@U03Q89DJPL4> is looking at this class of issue! Sorry you're running into it

Hey <@U04M931EM1A> thanks for the feedback. This is something we’re aware of and looking to address in the coming days

Screen Shot 2023-03-06 at 1.55.14 PM.png

Screen Shot 2023-03-06 at 1.54.49 PM.png

this might be related, but the icons showing the reviewer status on that PR also can't seem to decide what state the PR is in - they keep swapping between these two when I navigate between the PR and my dashboard

<@U02DCQ1C0G6> / <@U04HQKF7TSN> do you know if this is the same issue? <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1675837387048919>

<@U045W8WMUN5> It’s probably a different issue. Do you by chance have any automations on the PRs that cause it to be updated (eg. an app or bot posting comments or changing the status of the PRs)?

I don’t believe so, at least not at the time. But Aryaman and Jacob are taking a look in my old thread. Thank you for the help <@U02DCQ1C0G6>!

<@U02DCQ1C0G6> No automations, and the PR status isn't changing - I can reproduce it indefinitely by going to the PR, waiting for the status to update, going back to the dashboard, and refreshing.

Got it <@U04M931EM1A>, the updates we're making to the PR inbox page should address this issue

Screen Shot 2023-03-06 at 5.45.16 PM.png

Screen Shot 2023-03-06 at 5.45.30 PM.png

I’ve run `gt ss` locally and all changes have been successfully pushed to the remote branches

That's so weird, sorry this is happening! cc <@U02E95J4648>

Hm, sorry <@U04NBD0JU83> <@U04RHFT75N0>! Can you try running `gt ss --always` on your stack (using the latest CLI version) and see if that fixes? It will push your stack and all deps to graphite, hopefully fixing the remote state

Just tried it, no change! CLI still shows a stack and Dashboard shows no stack. Let me know if there are any other details I can share that would help with diagnosis!

Btw I just upgraded to v0.20.14 and ran the command but nothing has changed

hm, thanks for trying that! Let me loop in <@U02RREE9GKH> who is our resident expert at PR dependencies

<@U02RREE9GKH> <@U02E95J4648> I’m still seeing the “Not on default branch” issue in the dashboard. Any other steps I can try on my end to resolve this?

Plus one on "Are there any other steps I can try to resolve this?". This has become quite painful as it is affecting every stack I create!

Hi guys, sorry this is still happening! Let me get someone to look into this

Have you guys renamed your working repo recently?

Yes we did! I do see the old name when I run `gt repo name`

Ah that makes sense - we're having an issue with syncing renamed repositories in the dashboard, <@U02DGG36CSH> or <@U0486U7UUF3> should be able to fix this on a case-by-case basis for y'all while we iron out that issue

It might also be worth mentioning that I don’t have a local `.graphite_repo_config` file in this repository. My guess is that when I ran `gt repo init` ~5 months ago this config file didn’t exist. I tried re-running that command but no config file was generated. Should we try manually creating this file? If so, what structure/values should I use?

Broadly — you shouldn't need to ever edit that file manually

<@U04NBD0JU83> do you mind messaging me what the repo was renamed to and from?

Yes! We did rename ours too, but I'm the only person in our team who is having this issue!

<@U04RHFT75N0> let me know if you need help resolving also! you can dm me what the repo was renamed to and from and I can investigate. we're also working on a longer term solution that can handle repo name changes so that these problems don't happen in the future

Hey there, just reporting that I’m getting the same issue and there was no repo renaming involved. re-submitting with `--always` didn’t fix, and I’m running on 0.20.15. Is there any fix I can do to get this resolved?

Hey Sebastien, sorry for the delayed response. Can you confirm that you have the repo that they’re contributing to selected as part of your default repos?

And also that you are being tagged as a reviewer on the pull requests?

yes, it's a default repo and I'm being tagged as a reviewer

<@U04HFQACVT5> -- could you DM me the org/repo/number of the PR where this is happening? I can look at our logs

Hi, using graphite for the first time, but keep getting 504 errors

hmm sorry you're running into this!!! cc <@U02RREE9GKH>

apparently both PRs were created even though it gave a 504 after the first one

That's strange. Are you still seeing 504s with the CLI now?

I didn’t just now when restacking and submitting, but I’ll try again in a few min after fixing a bug first :sweat_smile:

Oh interesting - we'll take a look! Thanks for reporting :slightly_smiling_face:

Hi Joren, I'm sorry you ran into this. We have been dealing with the memory issues that are leading to occasional 504. From what you have described, it sounds like that is what you encountered. We are actively working on the issue and hope to have a resolution soon.

The second time it created my first pr, but got an 504 at the second

Hi <@U0394V215N1>!! Sorry about the confusion on this doc - I'll go ahead and make a few changes here to make this a bit clearer. A few things:
• I believe the main issue here is that for collaboration on a stack, you want to `gt downstack get &lt;uppermost branch in the stack&gt;`, which will bring all PRs in the stack into your workspace. This isn't clarified in the docs, so thanks for pointing that out!
• We've actually navigated our docs to <http://graphite.dev/docs|graphite.dev/docs>, curious to know where you got this docs link (to know if we need to update the link somewhere on our website or otherwise)

Thanks for the response.

• I probably got to this docs page from the auto-complete in Chrome
• Here is a scenario which should probably also be described in the doc:
    ◦ dev 1 creates a stack
    ◦ dev 2 does `gt downstack get &lt;uppermost branch in the stack&gt;`
    ◦ dev 1 adds another branch to the stack
    ◦ what does dev 2 do in that case to get their stack up-to-date?


The gt restacking ignores the smudge filter setting. I have some environment files that are only available locally. Every developer has different versions, so I naturally put the file list in .gitignore and set up a smudge filter in the .git/config file. Do you happen to know how to make such Git config filters work well with gt restacking? Or are there any good ways to keep local-only files safe even with frequent branch restacking?

CleanShot 2023-03-07 at 12.34.37@2x.png

`gt commit amend` also doesn’t let me edit the commit message. I’m not sure if that ever was supported though. `gt downstack edit` works properly though.

the "[Re: lines ...]" and the graphite_hidden span

Hey Lowell, I believe this shows up because you commented on a line outside of the range that GitHub allows you to comment on.

Graphite adds “[Re: lines ...]” so that other viewers know which lines you’re actually referring to, and we add the hidden span so that we can keep track of where the comment is and show it in the correct lines on Graphite.

I’d expect that teal one at the top to be further down the list, either above or below the pink stack. When I have a lot of branches, it’d be great for the older ones to be consistently at the top.

the sorting is deterministic, and I believe should be by committer date per list of direct children of a branch, which gets updated on any changes including restack.  was 0306 not restacked since the rest of them were?

:warning:  implementation details ahead (just typing out my own thought stream in case anyone find it interesting :slightly_smiling_face: ):

it might be slightly off that because the sorting happens  when we load the git state into memory at the ~beginning of the command~ ah typing this out helped me figure out what the bug might be — we don't reload git state into memory at the beginning of each command, only when we perform a disk cache invalidation.  so the sorting only corrects itself when you run direct git commands that modify branches.

anyway, i think the fix here is just to do explicit sorting at the actual `gt log` layer instead of relying on the git cache state...

(and also so i can paste screenshots of this thread into the linear task lol).  anyway, thanks for reporting!

haha, I love hearing implementation details

And I think you might be right. As for your question, I did restack everything, probably at the same time.

I just ran `gt rs --force --restack` and here’s where I landed:

About to merge a PR to cut this down to 1 newline

I guess the editor has your cursor information in place and it could be intelligent as far as inserting the new line(s) for you. You probably made it 2 for people that paste in the image right after typing text, but I guess I have a habit of adding my own line breaks first :stuck_out_tongue:

hey jacob! been a minute. It’s on `gt bs`

<@U03Q89DJPL4> is this tied to memory issues we've been seeing?

Based on the timing I don't think this is related to the memory issues we have been seeing. I do think we had some internal issues this morning that may be the cause. Does this issue recreate if you try again?