chore(projects): Increase project slug limit from 50 -> 100

[schew2381]

Increase project slug limit from 50 -> 100. There are no FE changes needed b/c we don't validate length on frontend, but show the error received from the failed POST request.

Also switch to using a constant for default slug length.

Closes https://github.com/getsentry/sentry/issues/73032 Closes ALRT-195

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

:white_check_mark: All tests successful. No failed tests found.

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #75737       +/-   ##
===========================================
+ Coverage   56.73%   78.39%   +21.66%     
===========================================
  Files        7053     6874      -179     
  Lines      311232   306538     -4694     
  Branches    50881    50115      -766     
===========================================
+ Hits       176573   240312    +63739     
+ Misses     130115    59800    -70315     
- Partials     4544     6426     +1882     

[schew2381]

This is a little tricky to run safely, just because we've seen an incident when widening a column before.

Running the analyze will fix the problem, however it takes a while to run, and if we end up locking on sentry_project then we'll be hard down until the analyze runs.

Mark and I discussed this on slack, and we have a couple of options that you could try:

Firstly, we could ask ops to duplicate sentry_project and then we could run a test on it. The steps here would be

• duplicate sentry_project to sentry_project_test
• Run an ANALYZE on sentry_project_test to make sure the stats are in a good state
• Take a copy of the stats for this column on the table https://redash.getsentry.net/queries/7220/source
• Get query plans for queries that use slug related indexes. This would be something like explain select * from sentry_project_test where organization_id = 1 and slug='sentry'
• Run the sql to widen the column
• Re-run the stats query and compare to the original, see if they have significantly changed
• Re-run the explain from above and compare it to before, see if it has significantly changed.

If things look good here, then we could ask ops to run these commands manually for us:

• Take a copy of the stats row from this query https://redash.getsentry.net/queries/7220/source. Convert it into an update statement, so that we can set the stats back onto the row if we see a problem
• ALTER TABLE "sentry_project" ALTER COLUMN "slug" TYPE varchar(100);
• Monitor sentry for any problems. If we see them, run the update statement from the first step. Note: We've never tried to perform stats surgery before, so this is a little risky. We should probably test it out on the test table from above first.
• If we're still seeing problems, run an analyze on the table

ok let me ask ops tmr

[schew2381]

Progress Tracking

• [x] Make a copy of sentry_project table called sentry_project_test - OPs Request

• [x] Run an ANALYZE on sentry_project_test to make sure the stats are in a good state - OPs Request

• [x] Take a copy of the stats for this column on the table https://redash.getsentry.net/queries/7220/source

• [x] Get query plans for queries that use slug related indexes. This would be something like explain select * from sentry_project_test where organization_id = 1 and slug='sentry'

• [x] Run the sql to widen the column - OPs Request

• [x] Re-run the stats query and compare to the original, see if they have significantly changed

• [x] Re-run the explain from above and compare it to before, see if it has significantly changed.

• [x] ask ops to run these commands manually for us:

  • [x] Take a copy of the stats row from this query https://redash.getsentry.net/queries/7220/source. Convert it into an update statement, so that we can set the stats back onto the row if we see a problem
  • [x] ALTER TABLE "sentry_project" ALTER COLUMN "slug" TYPE varchar(100);
  • [x] Monitor sentry for any problems. If we see them, run the update statement from the first step. Note: We've never tried to perform stats surgery before, so this is a little risky. We should probably test it out on the test table from above first.
  • [x] If we're still seeing problems, run an analyze on the table

[github-actions[bot]]

This PR has a migration; here is the generated SQL for src/sentry/migrations/0770_increase_project_slug_max_length.py ()

--
-- Alter field slug on project
--
ALTER TABLE "sentry_project" ALTER COLUMN "slug" TYPE varchar(100);