fix(platforms): Fix project platforms that are either 'python-tracing' or 'node-tracing' (#20568)

migrations_lockfile.txt

@@ -10,7 +10,7 @@ auth: 0008_alter_user_username_max_length
 contenttypes: 0002_remove_content_type_name
 jira_ac: 0001_initial
 nodestore: 0001_initial
-sentry: 0098_add-performance-onboarding
+sentry: 0099_fix_project_platforms
 sessions: 0001_initial
 sites: 0002_alter_domain_unique
 social_auth: 0001_initial

src/sentry/migrations/0099_fix_project_platforms.py

@@ -0,0 +1,54 @@
+# -*- coding: utf-8 -*-
+# Generated by Django 1.11.28 on 2020-09-02 21:33
+from __future__ import unicode_literals
+
+import logging
+
+from django.db import migrations
+
+from sentry.utils.query import RangeQuerySetWrapperWithProgressBar
+
+
+def fix_project_platform(apps, schema_editor):
+    """
+    Find projects whose platform is either 'python-tracing' or 'node-tracing',
+    and change them to be either 'python' or 'node' respectively.
+    """
+    Project = apps.get_model("sentry", "Project")
+
+    for project in RangeQuerySetWrapperWithProgressBar(Project.objects.all()):
+        try:
+            if project.platform == "node-tracing":
+                project.platform = "node"
+                project.save()
+                continue
+
+            if project.platform == "python-tracing":
+                project.platform = "python"
+                project.save()
+                continue
+        except Exception:
+            logging.exception("Error changing platform for project {}".format(project.id))
+
+
+class Migration(migrations.Migration):
+    # This flag is used to mark that a migration shouldn't be automatically run in
+    # production. We set this to True for operations that we think are risky and want
+    # someone from ops to run manually and monitor.
+    # General advice is that if in doubt, mark your migration as `is_dangerous`.
+    # Some things you should always mark as dangerous:
+    # - Large data migrations. Typically we want these to be run manually by ops so that
+    #   they can be monitored. Since data migrations will now hold a transaction open
+    #   this is even more important.
+    # - Adding columns to highly active tables, even ones that are NULL.
+    is_dangerous = True
+
+    # This flag is used to decide whether to run this migration in a transaction or not.
+    # By default we prefer to run in a transaction, but for migrations where you want
+    # to `CREATE INDEX CONCURRENTLY` this needs to be set to False. Typically you'll
+    # want to create an index concurrently when adding one to an existing table.
+    atomic = False
+
+    dependencies = [("sentry", "0098_add-performance-onboarding")]
+
+    operations = [migrations.RunPython(code=fix_project_platform)]

src/sentry/static/sentry/app/data/platformCategories.tsx

@@ -93,9 +93,7 @@ export const sourceMaps: PlatformKey[] = [
   'electron',
 ];
 
-// TODO(epurkhiser): I've added these since there was a need to have them in
-// the platform key type. However I have not added them anywhere else.
-const tracing = ['python-tracing', 'node-tracing'] as const;
+export const tracing = ['python-tracing', 'node-tracing'] as const;
 
 export type PlatformKey =
   | typeof popular[number]

src/sentry/static/sentry/app/data/platforms.tsx

@@ -3,6 +3,8 @@ import {PlatformIntegration} from 'app/types';
 import {platforms} from 'integration-docs-platforms';
 import {t} from 'app/locale';
 
+import {tracing} from './platformCategories';
+
 const otherPlatform = {
   integrations: [
     {
@@ -19,6 +21,10 @@ const otherPlatform = {
 export default ([] as PlatformIntegration[]).concat(
   [],
   ...[...platforms, otherPlatform].map(platform =>
-    platform.integrations.map(i => ({...i, language: platform.id}))
+    platform.integrations
+      .map(i => ({...i, language: platform.id}))
+      // filter out any tracing platforms; as they're not meant to be used as a platform for
+      // the project creation flow
+      .filter(integration => !(tracing as readonly string[]).includes(integration.id))
   )
 );