[v7] Deprecated Enums Removal

[AbhiPrasad]

Problem Statement

Last December, we made some efforts to deprecate enums as they add excess bundle size. We plan to remove these in v7.

Here is a list of them, alongside things we must consider.

Solution Brainstorm

Will be deleted

Status

b177690

export type EventStatus =
 /** The status could not be determined. */
 | 'unknown'
 /** The event was skipped due to configuration or callbacks. */
 | 'skipped'
 /** The event was sent to Sentry successfully. */
 | 'rate_limit'
 /** The client is currently rate limited and will try again later. */
 | 'invalid'
 /** The event could not be processed. */
 | 'failed'
 /** A server-side error occurred during submission. */
 | 'success';

This is an internally used enum, so we can delete this without much repercussions.

SessionStatus

https://github.com/getsentry/sentry-javascript/blob/master/packages/types/src/sessionstatus.ts

export enum SessionStatus {
 /** JSDoc */
 Ok = 'ok',
 /** JSDoc */
 Exited = 'exited',
 /** JSDoc */
 Crashed = 'crashed',
 /** JSDoc */
 Abnormal = 'abnormal',
}

An internal enum, we can delete!

RequestSessionStatus

export enum RequestSessionStatus {
/** JSDoc /
Ok = 'ok',
/* JSDoc /
Errored = 'errored',
/* JSDoc */
Crashed = 'crashed',
}

An internal enum, we can delete!

Up for debate

Severity

export enum Severity {
 /** JSDoc */
 Fatal = 'fatal',
 /** JSDoc */
 Error = 'error',
 /** JSDoc */
 Warning = 'warning',
 /** JSDoc */
 Log = 'log',
 /** JSDoc */
 Info = 'info',
 /** JSDoc */
 Debug = 'debug',
 /** JSDoc */
 Critical = 'critical',
}

The Severity enum was removed in dd3aa70, but was later undeprecated in #4412.

The Severity enum is part of the public API - captureMessage call, so possibly would require a lot of user facing changes (they have to go in and change a bunch of methods). Do we decide to still move on with removing the enum?

sentry-javascript/packages/hub/src/hub.ts

Line 227 in 4e722eb

public captureMessage(message: string, level?: Severity, hint?: EventHint): string {

SpanStatus

https://github.com/getsentry/sentry-javascript/blob/master/packages/tracing/src/spanstatus.ts

export enum SpanStatus {
 /** The operation completed successfully. */
 Ok = 'ok',
 /** Deadline expired before operation could complete. */
 DeadlineExceeded = 'deadline_exceeded',
 /** 401 Unauthorized (actually does mean unauthenticated according to RFC 7235) */
 Unauthenticated = 'unauthenticated',
 /** 403 Forbidden */
 PermissionDenied = 'permission_denied',
 /** 404 Not Found. Some requested entity (file or directory) was not found. */
 NotFound = 'not_found',
 /** 429 Too Many Requests */
 ResourceExhausted = 'resource_exhausted',
 /** Client specified an invalid argument. 4xx. */
 InvalidArgument = 'invalid_argument',
 /** 501 Not Implemented */
 Unimplemented = 'unimplemented',
 /** 503 Service Unavailable */
 Unavailable = 'unavailable',
 /** Other/generic 5xx. */
 InternalError = 'internal_error',
 /** Unknown. Any non-standard HTTP status code. */
 UnknownError = 'unknown_error',
 /** The operation was cancelled (typically by the user). */
 Cancelled = 'cancelled',
 /** Already exists (409) */
 AlreadyExists = 'already_exists',
 /** Operation was rejected because the system is not in a state required for the operation's */
 FailedPrecondition = 'failed_precondition',
 /** The operation was aborted, typically due to a concurrency issue. */
 Aborted = 'aborted',
 /** Operation was attempted past the valid range. */
 OutOfRange = 'out_of_range',
 /** Unrecoverable data loss or corruption */
 DataLoss = 'data_loss',
}

SpanStatus is another that has big savings if deleted, but provides a high amount of UX because it allows user's to see what exactly to set status to. We use it all around the docs (see the first example in https://docs.sentry.io/platforms/javascript/performance/instrumentation/custom-instrumentation/). Should we delete this?

[lforst]

Id make the decision based on a few factors:

• How big is the effort for the user to adopt? (probably a lot bigger for Severity that for SpanStatus)
• How big are the actual bundle savings?

Based on a gut feeling, I would not delete either of Severity and SpanStatus. I believe the effect of removing Severity would be too big with it being part of the captureMessage API. And SpanStatus, as you already mentioned, is quite valuable DX wise.

---

Additional Brainstom:

We might be able to save a tiny bit of bundle size save if we convert the enums into a plain objects.

[smeubank]

if it is making the decision on a few - i would proceed with the ones where there is no doubt and we parking lot the others. If we have time during V7 betas we can make a decision then. Then the big decider for me is @lforst 2nd point how much bundle savings are there really to be had vs how much we could go ahead and ship to folks

[AbhiPrasad]

Closing as a decision has been made. We are not deprecating Severity and SpanStatus, but we are deprecating the rest of the enums.