Graphite Community

Another small thing: It was also jarring that the Cancel and Delete buttons in the modal don't feel standard at all (maybe cause they're extra small), and can't be keyboard focused.

(Maybe a different option is to have an undo button for destructive actions, like the way google does things in Google Calendar and their other products)

in general i'm a little suspicious of how much we have mapped to `esc`, esp as you point out the disastrous effects that could occur by undoing your work

sometimes i hit `esc` too much and i get backed out all the way to the root `/` url

every day for me! :rolling_on_the_floor_laughing: :sob:

we break standard tabbing flows wrt to buttons, inputs, etc

that said, it's hard to do right (says me, the person who definitely doesn't do it right all the time  O_O )

one related issue is discoverability of the shortcuts itself--often you don't know you might be triggering a kb shortcut in the first place

these discussions have been coming up internally, and i'm hoping we can prioritize taking a stronger look at this entire area of problem soon

in the short term though we should probably make sure you can't just accept that dialog by hitting escape

I think you can't already... I don't know how I accepted it,

I thought I clicked on the modal backdrop, but that's working now...

esc, esc will just open and close the modal but not destruct it

I don't think I hit enter... maybe I did...

you more or less had to have, or somehow you got the HTML to blue-ring focus around the button and hit space

those are the main options i can think of

i'm definitely prone to hitting enter sometimes though

it's at least more brushable sometimes than usual

the delete button must have blue ring focus, but without the blue ring

i mean, just practically we need them across the board, i think?

when the modal came up, I froze for a sec and thought, wait what do I do here

i'm leaning towards "actions that do a database write should be `cmd enter` to confirm, never `enter`"

this i think is the case for posting a comment, but also i think it should be the case for confirming a red danger modal

there's other work around showing you actual keyboard hints, options include:
• always put the shortcut hint in the button
• put it on mouse over
• OR preferences around always having it in the button
• hold the `cmd` key down and see the entire page's shortcuts
• ????

some are discoverable in the kb shortcut help popup, but AFAIK none of the contextual ones are ever displayed to the user at the time of the UI showing

David Balatero - changed status to Canceled for GT-8852 Users can easily delete their comments on accident via keyboard shortcuts

whoops, sorry about that churn, was playing with a Linear option.

anyways i have it filed, will chat more with another eng today if i can grab them

That's a pretty great and established pattern that's already in my fingers :smile:

Thanks for all the thought that's gone into this already.

image.png

Hi <@U05GY0ZBF19> — is it possible that your local remote origin is out of date?

I’m seeing from our logs that we’re trying to create a PR for the repo “andrewlee/mgrv-community-app” based on your local remote but that GitHub is telling us that no such repository exists:

```GraphqlResponseError: Request failed due to following response errors:
 - Could not resolve to a Repository with the name 'andrewlee/mgrv-community-app'.
    at response (/monologue/.yarn/cache/@octokit-graphql-npm-5.0.0-316da27aea-94c3f4fb6f.zip/node_modules/@octokit/graphql/dist-src/graphql.js:48:19)
    at runMicrotasks (&lt;anonymous&gt;)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)```

The path to ''andrewlee/mgrv-community-app'' in the local and remote branches is incorrect, how do I change it?

I think something went wrong and I want to reset and start over.

I tried checking the remote url with the command `"git remote -v"` and the path is fine. <@U02DGG36CSH>

```ERROR: Unexpected server response (500).

Headers:
  x-graphite-request-id: d86e0f15-28c8-410d-bcbc-53cc5c95ca0d

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}```

Can you run `gt repo remote` and `gt repo owner` for me and tell me the outputs?

Hi <@U03GCLPSQLQ> — I’d love to help. Do you mind sharing your GitHub handle? I’ll take a look into our logs to see what might be happening here

<@U02DGG36CSH>Yes, it’s @cheunjm . You can DM me if you need more detail, thanks!

Hi <@U03GCLPSQLQ> I just looked into the logs for your account over the past week, but unfortunately everything there looks smooth. :neutral_face:

Next time you run into this error, do you mind sending me a Slack message with the particular time at which this occurred? We’ll be able to do a deeper dive there and check everything that was also going on on the box at that time as well.

2. The image below appears on the PR itself:

I’m currently using Chrome on a Mac. How can I resolve this issue?

Hopefully want these errors to be resolved before moving onto the paid version

I don't remember renaming the branch, but in `gt ls` it's named `fix-silly`, but the other commands are complaining about `fix-silly-thing`

Neither branch exists at all in git. Any ideas how I can make Graphite forget about this branch?

ooh, that was some fun speedy output when I ran that

ooh, it's undocumented! and --help is lies :smile:

Y'all, this is :fire: !! I love that it's at the top of the page! There's an opportunity to do math here, either saying "Load 21 more files" or "Load the rest"

Also this might not be a bug, but do you have auto-retry logic here? Every time I click it, it loads right away. I wonder if you have it automatically retry if the page has recently loaded. But maybe you opted not to to avoid layout shifts when permalinking to comments? Feel free to disregard if this is expected behavior.

Graphite - High server CPU resulting in slower website ​*[Identified]*​ We are continuing to work on a fix for this incident.
 ​*Affected:*​
Dashboard, CLI,
 View incident button

I'm seeing a lot of CORS errors in the console
```Access to fetch at '<https://api.graphite.dev/v1/graphite/bootstrap>' from origin '<https://app.graphite.dev>' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.```

are you saying it's me :rolling_on_the_floor_laughing:

We’re essentially being accidentally ddos’d on and off

is that consistent with CORS errors in the console?

its our load balancer saying that our server is timing out

we’re working on both frontend and backend fixes to prevent the ddosing

Sorry it's been a tough week -- I hope you crack it soon

:pray: we’re close :slightly_smiling_face: <@U02DGG36CSH> has been a hero working on this

:tada: :tada: :tada: <@U02DGG36CSH> :heart: :heart: :heart:

Related, I submitted a comment on a PR and approved. The approval went through, but the comment is stuck in the saving state. There might be some improvement potential here with auto-retry.

And more broadly, service workers so the requests can be fired off in the background without needing to keep the page open, but that's a much bigger lift.

Graphite - High server CPU resulting in slower website ​*[Resolved]*​ This incident has been resolved.
 ​*Affected:*​
Dashboard, CLI,
 View incident button

Can you DM me your org name and a screenshot of the banner? If you’re at 10 repos then this is a bug. I’ll fix it today. 

Read <https://graphite-community.slack.com/archives/C02ENKC0A9X/p1689363910745029?thread_ts=1689360553.417659&amp;cid=C02ENKC0A9X|here> re how we determine the limit of 30 repos. Apologies for the error.

Turns out the issue was with me having been tagged in a PR on a repo that was only recently created

The 30 limit warning was erroneous, but didn't lead to any rate limiting etc

i.e., you should see a banner, but no repo limit in the banner msging

Screenshot 2023-07-16 at 3.46.43 PM.png

you’re in the right place! ooc im wondering what behavior you’d prefer from the bot in this case (since slack can’t render a HTML table)

1. strip the HTML tags out and render the content as text
2. hide HTML table elements entirely
3. something else?

yeah, stripping html and rendering as a tsv essentially might make sense

hiding html tables (and just saying like &lt;html table hidden&gt; or something) would also be fine in my case

got it! thanks for your feedback :slightly_smiling_face:

Screenshot 2023-07-16 at 7.36.39 PM.png

Hi there! Sorry this is happening :disappointed:

<@U02DGG36CSH> might know what's going on here!

Hi <@U05H628BS02>, I took a look in and found a bug. The fix should be deploying now and the issue should be fixed in about 2 hours!

The issue is fixed now. Let us know if you continue running into any issues :slightly_smiling_face:

<@U02E95J4648> will take a look here! Sorry you’re running into this!

Hi <@U04LAL86TSS>, it looks like we’re getting the following error from GitHub on submit:

```Request failed due to following response errors:
 - Could not resolve to a Repository with the name 'Mavenoid/troubleshooter'.```
Any chance you recently renamed your repo?

If so, I’d double check that your remote is up-to-date and then that Graphite’s caching of your remote info is also up-to-date (I’d check the info in your `.graphite_repo_config` )

Screenshot 2023-07-17 at 12.40.27 PM.png

&gt; Any chance you recently renamed your repo?
Nope.

Screenshot 2023-07-17 at 12.41.48 PM.png

Hi <@U04LAL86TSS>, I dug in and it looks like there’s an issue with your Graphite account’s GitHub auth. Do you mind navigating to “Settings” &gt; “Account Settings” and sending me a screenshot of what you see?

(you can get there by clicking on the profile picture icon in the top right of the web app)

Screenshot 2023-07-17 at 2.14.53 PM.png

This? The app is already installed in our repo (but not by me). It leaves PR comments.

Can you click “Install Graphite app”?

It looks like the app has been installed on your organization, but not by you which is the cause of the errors we’ve been seeing (in GitHub API terms, the organization has given users who install the app and have access to Mavenoid access to the Mavenoid organization, but users still have to authorize the app to act on their behalf)

Screenshot 2023-07-17 at 2.17.47 PM.png

When I click thru all that “install” process, I end up here.

btw, all of this WAS working until today.

HEY!! After I closed the Github tab, I had a “Sync Permissions” button, and that fixed it.

Woohoo! Some puzzling behavior here that I’ll keep digging into on our side, but glad to hear this is fixed :slightly_smiling_face:

Your submit should work again as well — I just tested and our API can see the aforementioned repo for your user again

i have a ticket for myself to look at this one, i'll fix the tab indexing in that box

i can ping back here when it's fixed, probably in the next week or less

update: tabbing to and from the `&lt;textarea&gt;` inputs on the PR review page should feel much better now

definitely been seeing it... a lot of it seems like jank from loading things in after a scroll happens, but maybe there are other root causes too

Thanks for flagging! We're looking into making this experience better :')

Thank you! I'll keep an eye out to see if there are any reliable repro steps.

I see now the tab in the Github UI to “Open in Graphite”, was this a recent change?

ah makes sense. I’ve been off the code for a hot sec :flushed:

Personally, I prefer the optout (autoredirect + disable the plugin/no-redirect query string) to the opt-in, but I’ll survive if thats not reasonable

Reasonable! In the limit we'd like to make this configurable, especially if we have the time to add more functionality to the extension, but as long as it's super simple, we wanted to keep it less heavy handed

If it was intentional, I think y'all need to communicate things like this more loudly and clearly. I thought maybe I missed something obvious, but  <https://graphite-community.slack.com/archives/C02DRNL3HQU/p1687377494518029?thread_ts=1687377239.232329&amp;cid=C02DRNL3HQU|late July/early August> is all I can find in Slack. :disappointed:

<@U045W8WMUN5> we’re doing a phased rollout here. For now you’ll still be able to submit your stacks - this is a prompt but not a hard blocker.

Ahh, false alarm, I'm sorry. I was getting no-ops when I expected changes to be submitted, and thought the warning was blocking those changes.

<@U042CEGKRKM> Just wanted to confirm if I understand the phased rollout of this right. Before Aug 7 we will see warnings in the CLI &amp; UI, but there will be no active restrictions. Starting from Aug 7 if we stay on the free tier - the limits will kick in?

It's extra frictionful since the buttons can't be keyboard-focused, but I know that's on the way.

I've definitely run into this personally too - noted!

fixed this one, it's in the release pipeline and will go out whenever it makes it all the way through deploy

resolved! let us know if you see any other flakiness

Screenshot 2023-07-18 at 3.23.01 PM.png

cc <@U02DGG36CSH> who has been adjusting this today

There are a bunch of people in the null state of the typeahead but it looks like it doesn’t actually load more results ever :confused:

Ah <@U02E95J4648> this is actually related to the endpoint <@U04HQKF7TSN> is taking a look into (Aryaman can share more context here once he has a fix)

Screenshot 2023-07-18 at 3.26.25 PM.png

Screenshot 2023-07-18 at 3.27.06 PM.png

is this stack merging into the default branch of your repository?

Sorry, there’s a UI bug I recently introduced while improving CI - a fix should be in shortly!

(what i wanted was a separate branch for commit X, before "branch" and after "parent")

i worked around it by creating a branch on X manually, and then restacking "branch" onto X. now the commit hash is shown correctly in `gt branch split`

Hmm strage - thanks for flagging! Will see if we can repro and will plan to fix during our CLI changes this quarter :))

Ooh thanks for flagging this! Memes are important, we'll create a ticket :')

We didn’t remove old versions from NPM intentionally, let me look into what happened there. 

If you check the versions tab, only the current version is listed on NPM.

This is the error we are getting in our logs:
```error An unexpected error occurred: "<https://registry.yarnpkg.com/@withgraphite/graphite-cli/-/graphite-cli-0.20.22.tgz>: Request failed \"404 Not Found\"".```
We fixed it by upgrading our dependency to the current release.

It would be great if the old versions could be restored so we build old versions of our code again.

hmm, unfortunately NPM doesn't seem to be letting me fix this by republishing our old versions.  I am reaching out to their support team to see if we can get them restored.

Out of curiousity, why does your code have a dependency on the graphite-cli? It's generally intended for use as a user-invoked CLI tool

We depend on it as a dev dependency. It was the easiest way to integrate the tool into our development environment.

Very sorry about the inconvenience, did bumping the version fix everything or is there anything else here that we might need to help with?

You still need to update your cli install docs as they still say to use the GitHub repo.

We were in the process of switching from using the GitHub repo to NPM because of the process of updating the CLI. With NPM, we can update the code in our mono repo and once everyone syncs and rebuilds, they have the updated tool. That is why both changes caused trouble for us.