Merge branch 'master' into chore/try-auto-n

* master:
  fix(server): Do not 429 for event-only attachments (#647)
  doc(config): Remove references to advanced data scrubbing (#648)
  fix(server): Never respond with 429 for minidumps (#646)
  docs(config): Update relay end user documentation (#641)
  license: Update BSL change date
  fix: Add missing .NET 4.8 patches (#642)
  feat(server): Emit attachment sizes to Kafka (#644)
  fix(store): Use clock drift normalizer to correct all timestamp issues  (#634)
  feat(server): Emit flags for rate limited attachments (#640)
  feat(server): Enforce attachment size in rate limits (#639)
  feat(server): Apply quotas per item (#636)

CHANGELOG.md

@@ -2,10 +2,22 @@
 
 ## Unreleased
 
+**Features**:
+
+- Sessions and attachments can be rate limited now. These rate limits apply separately from error events, which means that you can continue to send Release Health sessions while you're out of quota with errors. ([#636](https://github.com/getsentry/relay/pull/636))
+
 **Bug Fixes**:
 
 - Outcomes from downstream relays were not forwarded upstream. ([#632](https://github.com/getsentry/relay/pull/632))
 - Apply clock drift correction to Release Health sessions and validate timestamps. ([#633](https://github.com/getsentry/relay/pull/633))
+- Apply clock drift correction for timestamps that are too far in the past or future. This fixes a bug where broken transaction timestamps would lead to negative durations. ([#634](https://github.com/getsentry/relay/pull/634))
+- Respond with status code `200 OK` to rate limited minidump and UE4 requests. Third party clients otherwise retry those requests, leading to even more load. ([#646](https://github.com/getsentry/relay/pull/646), [#647](https://github.com/getsentry/relay/pull/647))
+
+**Internal**:
+
+- Restructure the envelope and event ingestion paths into a pipeline and apply rate limits to all envelopes. ([#635](https://github.com/getsentry/relay/pull/635), [#636](https://github.com/getsentry/relay/pull/636))
+- Pass the combined size of all attachments in an envelope to the Redis rate limiter as quantity to enforce attachment quotas. ([#639](https://github.com/getsentry/relay/pull/639))
+- Emit flags for rate limited processing attachments and add a `size` field. ([#640](https://github.com/getsentry/relay/pull/640), [#644](https://github.com/getsentry/relay/pull/644))
 
 ## 20.6.0
 

LICENSE

@@ -16,7 +16,7 @@ Additional Use Grant: You may make use of the Licensed Work, provided that you d
                       error-reporting or application monitoring features of the
                       Licensed Work.
 
-Change Date:          2023-06-01
+Change Date:          2023-07-01
 
 Change License:       Apache License, Version 2.0
 

docs/.gitignore

@@ -1 +1 @@
-metrics.md
+configuration/metrics.md

docs/configuration/modes.md

@@ -0,0 +1,55 @@
+# Relay Modes
+
+When configuring a Relay server, the most important thing it is to understand the major modes in which it can operate.
+
+As seen in the introduction, the configuration file contains a `relay.mode` field. Currently, there are three modes that can be specified: `managed`, `static`, `proxy`.
+
+Event processing in Sentry can be configured using a two level hierachical configuration. At the top level, there are organization wide settings. An organization contains projects and event processing can be controlled with settings at project level.
+
+From Relay's point of view, events are processed according to the settings of the project it belongs to. Sentry includes all organization settings, such as organization-wide privacy controls, into settings of all projects belonging to your organization. The mode controls the way Relay obtains these project settings.
+
+## `managed` Mode
+
+This is the default mode in which Relay operates. To activate managed mode, set this configuration:
+
+```yaml
+relay:
+  mode: managed
+```
+
+Since configuration is obtained from Sentry, authentication is required in this mode. If authentication fails, no events will be accepted by Relay.
+
+As Relay receives events from applications, it will request project configurations from Sentry in order to process the events. If Sentry is unable to provide the configuration for a particular project, all messages for that project will be discared.
+
+Configuration is refreshed in regular intervals. See [Configuration Options] for ways to configure intervals, timeouts and retries.
+
+## `static` Mode
+
+In this mode, projects must be configured manually. To activate static mode, set this configuration:
+
+```yaml
+relay:
+  mode: static
+```
+
+In static configuration, Relay will process events only for statically configured projects and rejects events for all other projects. This is useful when you know the projects sending events upfront, and you wish to explicitly control the projects that are allowed to send events through this Relay.
+
+To configure projects, add files of format `projects/<PROJECT_ID>.json` to your Relay configuration folder. For a description of the contents of this file, refer to [Project Configuration].
+
+**Note:** In `static` mode, Relay does not register with upstream since it does not query information from it. After processing events for the configured projects, it forwards them to the upstream with the authentication information (DSN) set by the client that sent the original request.
+
+## `proxy` Mode
+
+This mode is similar to `static` mode but it forwards events from unknown projects. To activate proxy mode, set this configuration:
+
+```yaml
+relay:
+  mode: proxy
+```
+
+In `proxy` mode, events for statically configured projects are handled identically to `static` mode. Events for unknown projects -- projects for which there are no statically configured settings -- are forwarded (proxied) with minimal processing.
+
+**Note:** Rate limiting is still being applied in `proxy` mode for all projects regardless of whether they are statically configured or proxied.
+
+[configuration options]: ../options
+[project configuration]: ../projects