You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: develop-docs/engineering-practices/commit-messages.mdx
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,13 +16,13 @@ sidebar_order: 10
16
16
17
17
### Merge vs Rebase
18
18
19
-
Sentry uses a rebase workflow. That means that every commit on its own should be a clear, functional, and stable change. This means then when you’re building a new feature, you should try to pare it down into functional steps, and when that’s not reasonable, the end patch should be a single commit. This is counter to having a Pull Request which may include “fix [unmerged] behavior”. Those commits should be squashed, and the final patch when landed should be rebased.
19
+
Sentry uses a rebase workflow. That means that every commit on its own should be a clear, functional, and stable change. This means that when you’re building a new feature, you should try to pare it down into functional steps, and when that’s not reasonable, the end patch should be a single commit. This is counter to having a Pull Request which may include “fix [unmerged] behavior”. Those commits should be squashed, and the final patch when landed should be rebased.
20
20
21
21
Remember: each commit should follow the commit message format and be stable (green build).
22
22
23
23
#### Rebase and Merge
24
24
25
-
The GitHub UI exposes a “Rebase and Merge” option, which, if your commits are already in following the commit guidelines, is a great way to bring your change into the codebase.
25
+
The GitHub UI exposes a “Rebase and Merge” option, which, if your commits already follow the commit guidelines, is a great way to bring your change into the codebase.
26
26
27
27
#### Squashing
28
28
@@ -46,7 +46,7 @@ The header has a special format that includes a type, a scope and a subject:
46
46
47
47
The **header** is mandatory and the **scope** of the header is optional. If you have a Jira issue to link to, add the **jira-id** the commit belongs to. This helps to connect changes back to Jira tickets.
48
48
49
-
Any line of the commit message should not be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
49
+
Any line of the commit message should not be longer than 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
50
50
51
51
The footer should contain a closing reference to an issue as well as a relevant Sentry issue if any.
If the `message` in a breadcrumb contains an URL it should be formatted the same way as in `http` spans (see above).
118
-
If query strings are present in the URL or fragments (Browser SDKs only) are present in the URI, both should also be set in the data attribute like with `http` spans.
Fields in the event payload that allow user-specified or dynamic values are restricted in size. This applies to most meta data fields, such as variables in a stack trace, as well as contexts, tags and extra data:
139
-
140
-
- Event IDs are limited to 36 characters and must be valid UUIDs.
141
-
- Flag keys are limited to 32 characters.
142
-
- Flag values are limited to 200 characters.
143
-
- Tag keys are limited to 200 characters.
144
-
- Tag values are limited to 200 characters.
145
-
- Culprits are limited to 200 characters.
146
-
- Context objects are limited to 8kB.
147
-
- Individual extra data items are limited to 16kB. Total extra data is limited to 256kb.
148
-
- Messages are limited to 8192 characters.
149
-
- HTTP data (the body) is limited to 8kB. Always trim HTTP data before attaching it to the event.
150
-
- Stack traces are limited to 50 frames. If more are sent, data will be removed from the middle of the stack.
151
-
- Input messages in AI integrations recorded in the span attribute `gen_ai.request.messages` are limited to 20kB per span. Messages are trimmed and truncated if they exceed the limit, retaining the most recent messages.
152
-
153
-
Additionally, size limits apply to all store requests for the total size of the request, event payload, and attachments. Sentry rejects all requests exceeding these limits. Please refer the following resources for the exact size limits:
Copy file name to clipboardExpand all lines: develop-docs/sdk/expected-features/index.mdx
+3-168Lines changed: 3 additions & 168 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,173 +4,8 @@ description: The following is a description of features that are commonly expect
4
4
sidebar_order: 5
5
5
---
6
6
7
-
<Alerttitle="SDK Foundations"level="info">
8
-
Make sure to also read the <Linkto="/sdk/foundations/">Foundations</Link> documentation,
7
+
<Alerttitle="Content Moved"level="info">
8
+
Error monitoring features have been moved to the <Linkto="/sdk/telemetry/errors/">Errors</Link> telemetry spec.
9
+
See also the <Linkto="/sdk/foundations/">Foundations</Link> documentation,
9
10
including the <Linkto="/sdk/foundations/state-management/scopes/">Scopes</Link> and <Linkto="/sdk/foundations/client/">Client</Link> specs.
10
11
</Alert>
11
-
12
-
## Background Sending
13
-
14
-
Events should be transmitted in a background thread or similar system. This queue must be flushed when the
15
-
application shuts down with a specific timeout. This feature is typically user facing and explained
16
-
as part of [shutdown and draining](https://docs.sentry.io/platforms/javascript/configuration/draining/).
17
-
18
-
19
-
## Uncaught Exception Handler
20
-
21
-
Ability for the SDK to be set as a hook to record any uncaught exceptions. At the language level this is typically a global hook provided by the language itself. For framework integrations this might be part of middleware or some other system.
22
-
23
-
This behavior is typically provided by a default integration that can be disabled.
24
-
25
-
## Automatic Context Data
26
-
27
-
Automatic addition of useful attributes such as `flags` or `tags` or `extra` or specific `contexts`. Typically means the SDK hooks into a framework so that it can set attributes that are known to be useful for most users. Please check [Data Handling](/sdk/expected-features/data-handling) for considerations.
28
-
29
-
## Rate Limiting
30
-
31
-
Respect Sentry's HTTP 429 `Retry-After` header, or, if the SDK supports multiple payload types (e.g. errors and transactions), the `X-Sentry-Rate-Limits` header. Outgoing SDK requests should be dropped during the backoff period.
32
-
33
-
See <Linkto="/sdk/expected-features/rate-limiting">Rate Limiting</Link> for details.
34
-
35
-
36
-
## Backpressure Management
37
-
38
-
Backend SDKs (typically used in server applications) should have backpressure management logic that dynamically downsamples transactions when the throughput in the system is too high.
39
-
40
-
See <Linkto="/sdk/telemetry/traces/backpressure/">Backpressure Management</Link> for details.
41
-
42
-
## In-App frames
43
-
44
-
Stack parsing can tell which frames should be identified as part of the user's application (as opposed to part of the language, a library, or a framework), either automatically or by user configuration at startup, often declared as a package/module prefix.
45
-
46
-
## Surrounding Source in Stack Trace
47
-
48
-
Lines of source code to provide context in stack traces. This is easier in interpreted languages, may be hard or impossible in compiled ones.
49
-
50
-
## Local Variables
51
-
52
-
Local variable names and values for each stack frame, where possible. Restrictions apply on some platforms, for example it may only be possible to collect the values of parameters passed into each function, or it may be completely impossible to collect this information at all.
53
-
54
-
This functionality should be gated behind the `includeLocalVariables` option, which is `true` by default.
55
-
56
-
## Desymbolication
57
-
58
-
Turn compiled or obfuscated code/method names in stack traces back into the original. Desymbolication always requires Sentry backend support. Not necessary for many languages.
59
-
60
-
## Retrieve Last Event ID
61
-
62
-
Ability to get the ID of the last event sent. Event IDs are useful for correlation, logging, customers rolling their own feedback forms, etc.
63
-
64
-
## List Loaded Libraries
65
-
66
-
Include a list of loaded libraries (and versions) when sending an event.
67
-
68
-
## Buffer to Disk
69
-
70
-
This feature is also known as 'Offline Caching'.
71
-
72
-
Write events to disk before attempting to send, so that they can be retried in the event of a temporary network failure. Needs to implement a cap on the number of stored events. This is mostly useful on mobile and desktop(e.g: laptop) apps, where stable connectivity is often not available.
73
-
74
-
### Dealing With Network Failures
75
-
76
-
When SDKs receive an `HTTP 2xx` status code response from Sentry, they **MUST** consider it as a successful send.
77
-
78
-
If Sentry returns an `HTTP 4xx` or `HTTP 5xx` status code, SDKs **MUST** discard the envelope and record a [client report](/sdk/telemetry/client-reports/#network-failure-recording) as specified in the client reports spec.
79
-
80
-
For an [`HTTP 413 Content Too Large`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413) response, SDKs:
81
-
82
-
***MUST** discard the envelope and record a [client report](/sdk/telemetry/client-reports/#network-failure-recording).
83
-
***MUST NOT** retry sending the envelope.
84
-
***SHOULD** log an error, informing users that the envelope was discarded due to size limits.
85
-
***MAY** add information from the response body to the logged error. If doing so, SDKs **MUST** be aware that Relay can change or remove information in the response body for an `HTTP 413` at any time without notice.
86
-
87
-
For an [`HTTP 429 Too Many Requests`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429) response, SDKs:
88
-
89
-
-**MUST** respect the [rate limiting rules](/sdk/expected-features/rate-limiting/), such as correctly parsing the retry-header.
90
-
-**MUST** discard the envelope, but **MUST NOT** record a [client report](/sdk/telemetry/client-reports/#network-failure-recording), because the upstream already does this.
91
-
-**MUST NOT** retry sending the envelope.
92
-
93
-
SDKs **MAY** retry sending the envelope when a network error occurs, such as:
94
-
95
-
* Connection timeout
96
-
* DSN resolution failure
97
-
* Connection reset by peer
98
-
99
-
When other failures occur, like those caused by processing the file in the SDK itself, SDKs **MUST** discard the envelope and record a [client report](/sdk/telemetry/client-reports/#network-failure-recording) with the discard reason `internal_sdk_error`. Otherwise, the SDK might end up in an endless retry loop.
100
-
101
-
See the [Client Reports — Network Failure Recording](/sdk/telemetry/client-reports/#network-failure-recording) spec for the full set of client report recording requirements for each HTTP status code.
102
-
103
-
104
-
#### Additional capabilities
105
-
106
-
Consider having the SDK retry sending events once the device is back online, when such notification exists in the platform.
107
-
108
-
Once the device is back online, the SDK is likely going to empty its disk queue in a quick burst of requests. This can trigger different abuse filters in Sentry. To account for that, it's considered to add a small delay between cached event captures. A recommended value is 100 milliseconds.
109
-
110
-
If the SDK is being [rate-limited](/sdk/expected-features/rate-limiting/), which causes the SDK to drop any event that reaches its HTTP transport, consider stop consuming the disk cache until the `Retry-After` timeout is reached or the app restarts.
Ability to use an HTTP proxy. Often easy to implement using the existing HTTP client. This should be picked up from the system config if possible or explicit config in the client options.
159
-
160
-
## Attaching Request Body in Server SDKs
161
-
162
-
Ability for the SDK to attach request body to events and triggered during the execution of request.
163
-
164
-
User should be able to set a configuration option `maxRequestBodySize` to instruct SDK how big requests bodies should be attached.
165
-
SDK controls what is an actual size in bytes for each option:
166
-
167
-
-`none`
168
-
-`small` - `1000` bytes
169
-
-`medium` - `10000` bytes (default)
170
-
-`always`
171
-
172
-
## Log context
173
-
174
-
Some logging frameworks provide an option to set logging context. In Java this is called MDC (Mapped Diagnostic Context).
175
-
176
-
Users should be able to set a list of logging context entries in a configuration option `contextTags` to tell the SDK to convert the entries to Sentry tags.
|`trace_propagation_targets`|`array`| URL patterns for outgoing trace header injection. |
56
+
|`context_tags`|`array`| List of logging context keys to convert to Sentry tags. See [Log Context](#log-context). |
57
+
|`max_request_body_size`|`string`| Controls how large request bodies may be before the SDK skips attaching them. Server SDKs only. See [Request Body Size](#request-body-size). |
Server SDKs **SHOULD** support attaching the incoming HTTP request body to events. The `max_request_body_size` option controls the maximum body size the SDK will attach. The SDK defines the actual byte thresholds for each setting:
Some logging frameworks provide an option to set logging context. In Java this is called MDC (Mapped Diagnostic Context).
201
+
202
+
SDKs that integrate with platform logging frameworks **SHOULD** support a `context_tags` configuration option. This option accepts a list of logging context keys whose values the SDK converts to Sentry tags on captured events.
0 commit comments