# Dapr 1.12.3

This update includes bug fixes:

- [Fix timeouts in HTTP service invocation when resiliency policies with timeouts are applied](#fix-timeouts-in-http-service-invocation-when-resiliency-policies-with-timeouts-are-applied)
- [Fix dissemination of placement tables](#fix-dissemination-of-placement-tables)
- [Fix SQL Server state store not working with correctly case-sensitive collations](#fix-sql-server-state-store-not-working-correctly-with-case-sensitive-collations)
- [Fix Kafka Pub/sub consumer bottlenecks and long startup times when subscribing to multiple topics](#fix-kafka-pubsub-consumer-bottlenecks-with-multiple-topics)

## Fix timeouts in HTTP service invocation when resiliency policies with timeouts are applied

### Problem

In HTTP service invocation, in certain cases when a resiliency policy is applied (for example, one that includes timeouts), requests could be interrupted earlier with a "context deadline exceeded" error.

### Impact

Impacts users running Dapr 1.12.0-1.12.2 that use HTTP service invocation and who have resiliency policies applied

### Root cause

When resiliency policies with timeouts are applied, due to a bug the incorrect context was used while sending the response to the client, and in certain situations it could have been terminated earlier than the request.

### Solution

We fixed the code that handles HTTP service invocation to make sure the timeout is applied to the entire response.

## Fix dissemination of placement tables

### Problem

Placement nodes acquire a lock, disseminate the tables, and release the lock in parallel. The Placement stream disconnects before the dissemination of tables.

```
Error invoke actor method: failed to invoke target x after 3 retries
```

Placement server logs:

```
level=error msg="Stream is disconnected before member is added
```

### Impact

Impacts users running Dapr 1.12.0-1.12.2

### Root cause

Dissemination did not use a background context. The logic to acquire a lock, disseminate the tables, and release the lock were all occurring in parallel.

### Solution

Updated the Dapr Placement service to use a background context and follow a 3 step process to acquire a lock, disseminate the tables, and release the lock.

## Fix SQL Server state store not working correctly with case-sensitive collations

### Problem

When using a database with a case-sensitive collation, the SQL Server state store component did not work correctly. Certain operations, including those relied upon by the actor state store, were failing.

### Impact

Impacts users of Dapr 1.11.0-1.12.2

### Root cause

A stored procedure referenced a column named with the wrong case. This was causing errors on case-sensitive databases.

### Solution

We updated the stored procedure so it does use the correct case for column names.

## Fix Kafka Pub/Sub consumer bottlenecks with multiple topics

### Problem

When using Dapr with Kafka for Pub/Sub and subscribing to multiple topics, users might see bottlenecks in Kafka message processing and long init times when the Dapr sidecar is starting up.

### Impact

Impacts users of Dapr 1.11.0-1.12.2

### Root cause

When new topic subscriptions were added, Dapr would close the consumer group and recreate it, leading to partition rebalance across the cluster.

### Solution

The Kafka consumer logic was changed to not recreate the consumer group every time a new topic subscription is added.
