Merge branch 'v1.16' into feat-lock-redis-sentinel

This commit is contained in:
Nishchith Shetty 2025-08-27 11:05:50 -07:00 committed by GitHub
commit f8a8f7436a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
13 changed files with 213 additions and 13 deletions

View File

@ -39,7 +39,7 @@ jobs:
- name: Build Hugo Website - name: Build Hugo Website
run: | run: |
git config --global --add safe.directory /github/workspace git config --global --add safe.directory /github/workspace
hugo hugo --minify
- name: Deploy Website - name: Deploy Website
id: builddeploy id: builddeploy
uses: Azure/static-web-apps-deploy@v1 uses: Azure/static-web-apps-deploy@v1

View File

@ -111,6 +111,138 @@ If you decide to generate trace headers yourself, there are three ways this can
Read [the trace context overview]({{% ref w3c-tracing-overview %}}) for more background and examples on W3C trace context and headers. Read [the trace context overview]({{% ref w3c-tracing-overview %}}) for more background and examples on W3C trace context and headers.
### Baggage Support
Dapr supports two distinct mechanisms for propagating W3C Baggage alongside trace context:
1. **Context Baggage (OpenTelemetry)**
- Follows OpenTelemetry conventions with decoded values
- Used when working with OpenTelemetry context propagation
- Values are stored and transmitted in their original, unencoded form
- Recommended for OpenTelemetry integrations and when working with application context
2. **Header/Metadata Baggage**
- You must URL encode special characters (for example, `%20` for spaces, `%2F` for slashes) when setting header/metadata baggage
- Values remain percent-encoded in transport as required by the W3C Baggage spec
- Values stay encoded when inspecting raw headers/metadata
- Only OpenTelemetry APIs will decode the values
- Example: Use `serverNode=DF%2028` (not `serverNode=DF 28`) when setting header baggage
For security purposes, context baggage and header baggage are strictly separated and never merged between domains. This ensures that baggage values maintain their intended format and security properties.
#### Using Baggage with Dapr
You can propagate baggage using either mechanism, depending on your use case.
1. **In your application code**: Set the baggage in the context before making a Dapr API call
2. **When calling Dapr**: Pass the context to any Dapr API call
3. **Inside Dapr**: The Dapr runtime automatically picks up the baggage
4. **Propagation**: Dapr automatically propagates the baggage to downstream services, maintaining the appropriate encoding for each mechanism
Here are examples of both mechanisms:
**1. Using Context Baggage (OpenTelemetry)**
When using OpenTelemetry SDK:
{{< tabpane text=true >}}
{{% tab header="Go" %}}
```go
import otelbaggage "go.opentelemetry.io/otel/baggage"
// Set baggage in context (values remain unencoded)
baggage, err = otelbaggage.Parse("userId=cassie,serverNode=DF%2028")
...
ctx := otelbaggage.ContextWithBaggage(t.Context(), baggage)
)
// Pass this context to any Dapr API call
client.InvokeMethodWithContent(ctx, "serviceB", ...)
```
**2. Using Header/Metadata Baggage**
When using gRPC metadata:
```go
import "google.golang.org/grpc/metadata"
// Set URL-encoded baggage in context
ctx = metadata.AppendToOutgoingContext(ctx,
"baggage", "userId=cassie,serverNode=DF%2028",
)
// Pass this context to any Dapr API call
client.InvokeMethodWithContent(ctx, "serviceB", ...)
```
**3. Receiving Baggage in Target Service**
In your target service, you can access the propagated baggage:
```go
// Using OpenTelemetry (values are automatically decoded)
import "go.opentelemetry.io/otel/baggage"
bag := baggage.FromContext(ctx)
userID := bag.Member("userId").Value() // "cassie"
```
```go
// Using raw gRPC metadata (values remain percent-encoded)
import "google.golang.org/grpc/metadata"
md, _ := metadata.FromIncomingContext(ctx)
if values := md.Get("baggage"); len(values) > 0 {
// values[0] contains the percent-encoded string you set: "userId=cassie,serverNode=DF%2028"
// Remember: You must URL encode special characters when setting baggage
// To decode the values, use OpenTelemetry APIs:
bag, err := baggage.Parse(values[0])
...
userID := bag.Member("userId").Value() // "cassie"
}
```
*HTTP Example (URL-encoded):*
```bash
curl -X POST http://localhost:3500/v1.0/invoke/serviceB/method/hello \
-H "Content-Type: application/json" \
-H "baggage: userID=cassie,serverNode=DF%2028" \
-d '{"message": "Hello service B"}'
```
*gRPC Example (URL-encoded):*
```go
ctx = grpcMetadata.AppendToOutgoingContext(ctx,
"baggage", "userID=cassie,serverNode=DF%2028",
)
```
{{% /tab %}}
{{< /tabpane >}}
#### Common Use Cases
Baggage is useful for:
- Propagating user IDs or correlation IDs across services
- Passing tenant or environment information
- Maintaining consistent context across service boundaries
- Debugging and troubleshooting distributed transactions
#### Best Practices
1. **Choose the Right Mechanism**
- Use Context Baggage when working with OpenTelemetry
- Use Header Baggage when working directly with HTTP/gRPC
2. **Security Considerations**
- Be mindful that baggage is propagated across service boundaries
- Don't include sensitive information in baggage
- Remember that context and header baggage remain separate
## Related Links ## Related Links
- [Observability concepts]({{% ref observability-concept.md %}}) - [Observability concepts]({{% ref observability-concept.md %}})

View File

@ -48,7 +48,7 @@ When a request arrives without a trace ID, Dapr creates a new one. Otherwise, it
These are the specific trace context headers that are generated and propagated by Dapr for HTTP and gRPC. These are the specific trace context headers that are generated and propagated by Dapr for HTTP and gRPC.
{{< tabpane text=true >}} {{< tabpane text=true >}}
<!-- HTTP -->
{{% tab "HTTP" %}} {{% tab "HTTP" %}}
Copy these headers when propagating a trace context header from an HTTP response to an HTTP request: Copy these headers when propagating a trace context header from an HTTP response to an HTTP request:
@ -73,14 +73,67 @@ tracestate: congo=t61rcWkgMzE
[Learn more about the tracestate fields details](https://www.w3.org/TR/trace-context/#tracestate-header). [Learn more about the tracestate fields details](https://www.w3.org/TR/trace-context/#tracestate-header).
**Baggage Support**
Dapr supports [W3C Baggage](https://www.w3.org/TR/baggage/) for propagating key-value pairs alongside trace context through two distinct mechanisms:
1. **Context Baggage (OpenTelemetry)**
- Follows OpenTelemetry conventions with decoded values
- Used when propagating baggage through application context
- Values are stored in their original, unencoded form
- Example of how it would be printed with OpenTelemetry APIs:
```
baggage: userId=cassie,serverNode=DF 28,isVIP=true
```
2. **HTTP Header Baggage**
- You must URL encode special characters (for example, `%20` for spaces, `%2F` for slashes) when setting header baggage
- Values remain percent-encoded in HTTP headers as required by the W3C Baggage spec
- Values stay encoded when inspecting raw headers in Dapr
- Only OpenTelemetry APIs like `otelbaggage.Parse()` will decode the values
- Example (note the URL-encoded space `%20`):
```bash
curl -X POST http://localhost:3500/v1.0/invoke/serviceB/method/hello \
-H "Content-Type: application/json" \
-H "baggage: userId=cassie,serverNode=DF%2028,isVIP=true" \
-d '{"message": "Hello service B"}'
```
For security purposes, context baggage and header baggage are strictly separated and never merged between domains. This ensures that baggage values maintain their intended format and security properties in each domain.
Multiple baggage headers are supported and will be combined according to the W3C specification. Dapr automatically propagates baggage across service calls while maintaining the appropriate encoding for each domain.
{{% /tab %}} {{% /tab %}}
<!-- gRPC -->
{{% tab "gRPC" %}} {{% tab "gRPC" %}}
In the gRPC API calls, trace context is passed through `grpc-trace-bin` header. In the gRPC API calls, trace context is passed through `grpc-trace-bin` header.
**Baggage Support**
Dapr supports [W3C Baggage](https://www.w3.org/TR/baggage/) for propagating key-value pairs alongside trace context through two distinct mechanisms:
1. **Context Baggage (OpenTelemetry)**
- Follows OpenTelemetry conventions with decoded values
- Used when propagating baggage through gRPC context
- Values are stored in their original, unencoded form
- Example of how it would be printed with OpenTelemetry APIs:
```
baggage: userId=cassie,serverNode=DF 28,isVIP=true
```
2. **gRPC Metadata Baggage**
- You must URL encode special characters (for example, `%20` for spaces, `%2F` for slashes) when setting metadata baggage
- Values remain percent-encoded in gRPC metadata
- Example (note the URL-encoded space `%20`):
```
baggage: userId=cassie,serverNode=DF%2028,isVIP=true
```
For security purposes, context baggage and metadata baggage are strictly separated and never merged between domains. This ensures that baggage values maintain their intended format and security properties in each domain.
Multiple baggage metadata entries are supported and will be combined according to the W3C specification. Dapr automatically propagates baggage across service calls while maintaining the appropriate encoding for each domain.
{{% /tab %}} {{% /tab %}}
{{< /tabpane >}} {{< /tabpane >}}

View File

@ -39,7 +39,7 @@ spec:
metadata: metadata:
- name: url - name: url
value: "file://router.wasm" value: "file://router.wasm"
- guestConfig - name: guestConfig
value: {"environment":"production"} value: {"environment":"production"}
``` ```

View File

@ -95,6 +95,7 @@ The above example uses secrets as plain strings. It is recommended to use a [sec
| subscribeMode | N | Subscription mode indicates the cursor persistence, durable subscription retains messages and persists the current position. Default: `"durable"` | `"durable"`, `"non_durable"` | | subscribeMode | N | Subscription mode indicates the cursor persistence, durable subscription retains messages and persists the current position. Default: `"durable"` | `"durable"`, `"non_durable"` |
| partitionKey | N | Sets the key of the message for routing policy. Default: `""` | | | partitionKey | N | Sets the key of the message for routing policy. Default: `""` | |
| `maxConcurrentHandlers` | N | Defines the maximum number of concurrent message handlers. Default: `100` | `10` | `maxConcurrentHandlers` | N | Defines the maximum number of concurrent message handlers. Default: `100` | `10`
| replicateSubscriptionState | N | Enable replication of subscription state across geo-replicated Pulsar clusters. Default: `"false"` | `"true"`, `"false"` |
### Authenticate using Token ### Authenticate using Token

View File

@ -66,6 +66,8 @@ spec:
value: {podName} value: {podName}
- name: heartBeat - name: heartBeat
value: 10s value: 10s
- name: publishMessagePropertiesToMetadata
value: "true"
``` ```
{{% alert title="Warning" color="warning" %}} {{% alert title="Warning" color="warning" %}}
@ -102,7 +104,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
| clientKey | Required for using TLS | TLS client key in PEM format. Must be used with `clientCert`. Can be `secretKeyRef` to use a secret reference. | `"-----BEGIN RSA PRIVATE KEY-----\n<base64-encoded PKCS8>\n-----END RSA PRIVATE KEY-----"` | clientKey | Required for using TLS | TLS client key in PEM format. Must be used with `clientCert`. Can be `secretKeyRef` to use a secret reference. | `"-----BEGIN RSA PRIVATE KEY-----\n<base64-encoded PKCS8>\n-----END RSA PRIVATE KEY-----"`
| clientName | N | This RabbitMQ [client-provided connection name](https://www.rabbitmq.com/connections.html#client-provided-names) is a custom identifier. If set, the identifier is mentioned in RabbitMQ server log entries and management UI. Can be set to {uuid}, {podName}, or {appID}, which is replaced by Dapr runtime to the real value. | `"app1"`, `{uuid}`, `{podName}`, `{appID}` | clientName | N | This RabbitMQ [client-provided connection name](https://www.rabbitmq.com/connections.html#client-provided-names) is a custom identifier. If set, the identifier is mentioned in RabbitMQ server log entries and management UI. Can be set to {uuid}, {podName}, or {appID}, which is replaced by Dapr runtime to the real value. | `"app1"`, `{uuid}`, `{podName}`, `{appID}`
| heartBeat | N | Defines the heartbeat interval with the server, detecting the aliveness of the peer TCP connection with the RabbitMQ server. Defaults to `10s` . | `"10s"` | heartBeat | N | Defines the heartbeat interval with the server, detecting the aliveness of the peer TCP connection with the RabbitMQ server. Defaults to `10s` . | `"10s"`
| `publishMessagePropertiesToMetadata` | N | Whether to publish AMQP message properties (headers, message ID, etc.) to the metadata. | "true", "false"
## Communication using TLS ## Communication using TLS
@ -475,6 +477,11 @@ spec:
singleActiveConsumer: "true" singleActiveConsumer: "true"
``` ```
## Publishing message properties to metadata
To enable [message properties](https://www.rabbitmq.com/docs/publishers#message-properties) being published in the metadata, set the `publishMessagePropertiesToMetadata` field to `"true"` in the component spec.
This will include properties such as message ID, timestamp, and headers in the metadata of the published message.
## Related links ## Related links
- [Basic schema for a Dapr component]({{% ref component-schema %}}) in the Related links section - [Basic schema for a Dapr component]({{% ref component-schema %}}) in the Related links section

View File

@ -10,4 +10,11 @@
indexName: 'daprdocs', indexName: 'daprdocs',
}); });
</script> </script>
<!-- Start of Reo Javascript -->
<script type="text/javascript">
!function(){var e,t,n;e="5901cc15fcf7e10",t=function(){Reo.init({clientID:"5901cc15fcf7e10"})},(n=document.createElement("script")).src="https://static.reo.dev/"+e+"/reo.js",n.defer=!0,n.onload=t,document.head.appendChild(n)}();
</script>
<!-- End of Reo Javascript -->
{{ end }} {{ end }}

@ -1 +1 @@
Subproject commit d15a0234049c6ae0fd9d4e23af1fc0650c0c8a8a Subproject commit 241a646a2037d4e91d3192dcbaf1f128b15de185

@ -1 +1 @@
Subproject commit f4ba09fae50c634cad11050ff05485cb9ef65bf7 Subproject commit 6dd434913b6fb41f6ede006c64c01a35a02c458f

@ -1 +1 @@
Subproject commit f73d57eb27028bf41e9ab1fde3b50586ab5de919 Subproject commit 3bb91e505e34ef3b7bc3325be853de8d0491c431

@ -1 +1 @@
Subproject commit 26b3527e688751a2ffef812bec95790535218506 Subproject commit 26e8be8931aed2404e0e382b6c61264d1b64f0de

@ -1 +1 @@
Subproject commit b2f2988f397a34159e67fb30c6a0e2f414a60350 Subproject commit 5882d52961cee7cb50d07c9a47c902f317dff396

@ -1 +1 @@
Subproject commit 407447816c2107860af98897802c4491306e95d0 Subproject commit 4475ed57cfdcb912a828f43cace8c0bea3eb99e1