Releases

Dapr v1.18.1 is a focused bug-fix release for the workflow engine, patching five issues including reminder leaks, permanent sidecar unavailability after config reload, and stuck workflows.

• breakingHelm users: workflow concurrency limits were silently ignored before this release

  If you set globalMaxConcurrentWorkflowInvocations, globalMaxConcurrentActivityInvocations, or the per-name limit fields on a Configuration resource and installed via Helm, those limits were never enforced. After upgrading to 1.18.1 the CRD schema is correct and limits will actually take effect. Review your configured values before upgrading in production — limits that were previously ignored will now be applied, which could throttle throughput if the values are too conservative.

• enhancementUpgrade if you run agentic or long-running loop workflows

  Three bugs in this release specifically affect workflows that loop via ContinueAsNew or repeatedly await the same external event name — patterns common in agentic workloads. The reminder leak accumulates garbage reminders over a workflow's lifetime; the ContinueAsNew deadlock causes indefinite hangs with no timeout or error. Both are fixed here. If you see workflows stuck in RUNNING or observe spurious wake-ups in loop workflows, upgrade to 1.18.1.

• enhancementConfig hot-reload now works reliably for workflow sidecars

  Before this fix, any SIGHUP-triggered config reload on a sidecar hosting workflow workers could permanently break the sidecar — port 50001 stops accepting connections and the only recovery was a pod restart. This is now fixed. If your team uses config hot-reload in any workflow-hosting deployment, 1.18.1 should be treated as a required upgrade.

Dapr 1.17.10 fixes a bug where resiliency retry policies with `matching` rules on pubsub publish operations were silently ignored, causing terminal errors to be retried unnecessarily. Teams using pubsub with resiliency retry configuration should upgrade to enforce intended retry behavior.

• breakingRetry behavior change for pubsub publish errors

  If you have resiliency policies with `matching` rules targeting pubsub outbound retry, publish errors will now be classified correctly and non-retriable errors will stop retrying immediately instead of exhausting maxRetries. Verify your resiliency configuration expectations: terminal errors (e.g., 401 Unauthorized, 404 Not Found) will no longer consume retry attempts. If your application relied on the old behavior of always retrying publish, adjust your retry policy or remove the `matching` constraint.

• enhancementEnforce resiliency policy intent for pubsub

  Upgrade to 1.17.10 if you've configured resiliency policies with explicit `matching` codes for pubsub publish — your configuration will now work as intended. This brings pubsub publish in line with service invocation, output bindings, and other operations that already respect retry `matching`. No code changes needed; the fix is transparent.

Dapr 1.16.16 fixes two downgrade-specific bugs: Sentry certificate signing failures after a 1.18→1.16 rollback, and Helm StatefulSet storage conflicts when downgrading from 1.17/1.18.

• breakingFollow specific Helm flags when downgrading to 1.16.16

  Use --reset-values and explicitly pass the original install values. Do NOT use --reuse-values — it carries over 1.17/1.18 chart defaults that are invalid in 1.16, including placement disseminateTimeout=8s (1.16 only accepts 1s–3s), which will cause placement to fail at startup. If you skipped deleting the scheduler StatefulSet before downgrading, you may still need to pass --set dapr_scheduler.cluster.storageSize=<current size> or delete the StatefulSet with --cascade=orphan.

• breakingClusters downgraded from 1.18 to 1.16 need this patch to fix Sentry

  If you rolled back from Dapr 1.18 to any earlier 1.16.x release, Sentry is likely crashing on startup due to the Ed25519/ECDSA key type mismatch in the trust bundle. Upgrade to 1.16.16 to resolve it — no manual certificate rotation is required after upgrading.

Dapr 1.16.15 fixes a sentry crash that blocks all mTLS identity issuance when the issuer key is Ed25519 or RSA — directly relevant to anyone who downgraded from 1.18 or rotated their issuer key type.

• breakingUpgrade to 1.16.15 if you downgraded from 1.18 or rotated your issuer key

  If your 1.16 control plane has an Ed25519 or RSA issuer key in the dapr-trust-bundle secret — which happens automatically after a 1.18 downgrade — dapr-sentry crash-loops and no new mTLS certificates are issued. Existing sidecars with unexpired certs keep working, but any pod restart or cert expiry will cause identity failures. Upgrade to 1.16.15 immediately. If you cannot upgrade right now, the only workaround is to replace the issuer key in dapr-trust-bundle with an ECDSA P-256 key.

Dapr 1.18 is a large release centered on workflow security and durability (tamper detection, access policies, history propagation, concurrency limits), with Jobs API and HotReload graduating to GA and several breaking changes requiring pre-upgrade review.

• securityEnable WorkflowAccessPolicy in shared or multi-tenant clusters

  Before 1.18, any caller in the same trust domain could schedule, terminate, or query any other app's workflows. The new WorkflowAccessPolicy CRD lets you lock this down per-operation with glob-pattern rules. The default is still open (no policy = all calls allowed), so existing deployments are unaffected — but teams running shared clusters should define policies now. Also: redis common components previously skipped TLS cert verification unconditionally; this is fixed in 1.18, so verify your Redis TLS config is correct before upgrading.

• breakingDo not roll back from 1.18 directly to 1.17.6 or earlier

  Sentry 1.18 writes an Ed25519-keyed CA into the dapr-trust-bundle secret. Any Sentry version before 1.17.7 cannot parse this and will crash-loop, blocking all new certificate issuance. Before upgrading, confirm your rollback target is 1.17.7+. If you need to go below 1.17.7, downgrade to 1.17.7 first, stabilize, then continue. Also audit any code that relied on silent workflow ID reuse — it now gets a hard conflict error.

• breakingHop-by-hop headers stripped on service invocation — check your apps

  Standard HTTP hop-by-hop headers (Connection, Keep-Alive, Transfer-Encoding, etc.) are now stripped during service invocation per RFC 7230. Any app relying on these headers passing through will silently break. Audit service invocation call sites and move to non-hop-by-hop equivalents before upgrading.

• enhancementEnable workflow history signing for audit-sensitive workloads

  Workflow history signing is opt-in and disabled by default. It requires mTLS to be active. Before turning it on cluster-wide, let any in-flight unsigned workflows complete or purge them — enabling signing on a workflow that started unsigned is a hard verification error with no catch-up path. Once enabled, a tampered workflow is terminated and flagged with DAPR_WORKFLOW_HISTORY_TAMPERED, leaving the original state intact for forensic review. Good candidate for compliance-sensitive or multi-tenant workflow deployments.

v1.17.9 fixes a targeted bug where workflows using Azure Cosmos DB as their actor state store get permanently stuck in a purge loop when the customStatus row is absent.

• breakingUpgrade immediately if using Cosmos DB for workflow state

  Any deployment using state.azure.cosmosdb as the workflow actor state store is at risk. Affected workflows never get purged past their TTL, and the scheduler fires a purge attempt every second forever — burning CPU, generating log noise, and inflating your dapr_runtime_workflow_operation_count{status=failed} metrics. Upgrade to 1.17.9 and restart sidecars; stuck workflows recover on the next retention reminder fire automatically. No manual cleanup needed after upgrade.

• enhancementCheck metrics now to assess blast radius before upgrading

  Before upgrading, query dapr_runtime_workflow_operation_count with labels operation=purge_workflow and status=failed. A non-zero and growing count on a Cosmos DB deployment confirms you have stuck workflows. This tells you how many workflows will self-heal post-upgrade and gives you a clear before/after signal to verify the fix took effect.

v1.17.8 fixes two issues: workflows getting permanently stuck when reusing completed instance IDs, and a Sentry OIDC security flaw (CWE-346) that allows discovery document poisoning via X-Forwarded-Host.

• securityFix OIDC discovery document poisoning via X-Forwarded-Host

  Sentry OIDC deployments running without `--jwt-issuer` or `--oidc-allowed-hosts` are vulnerable to CWE-346: an attacker who can send requests with a forged `X-Forwarded-Host` header can poison the discovery document, and HTTP caches may serve the poisoned response for up to an hour. If you can't upgrade immediately, set `--jwt-issuer` (pins the issuer statically, simplest fix) or `--oidc-allowed-hosts`. If you use a reverse proxy that needs to advertise its public hostname via `X-Forwarded-Host`, set `--oidc-allowed-hosts` to your expected hostname — this is now required for that header to take effect.

• breakingUpgrade to fix stuck workflows with reused instance IDs

  Any workflow using deterministic/stable instance IDs is affected. After upgrading sidecars to 1.17.8, stuck workflows recover automatically on the next retention reminder fire — no manual scheduler cleanup needed. Check your `dapr_runtime_workflow_operation_count{operation=purge_workflow,status=failed}` metric; if it's incrementing at ~1/sec per workflow, you're hitting this bug.

Dapr v1.17.7 is a dense bug-fix release targeting workflow reliability, messaging correctness, and control-plane resilience. Fourteen production-grade fixes land here — upgrade if you run workflows, Kafka, or RabbitMQ.

• securityUpgrade sentry immediately if you downgraded from 1.18 or use Ed25519/RSA issuer keys

  A type-switch bug in dapr/kit caused sentry to crash on startup with 'unsupported key type' for Ed25519 and RSA issuer keys. Sentry enters a crash-loop, stops issuing mTLS identities, and halts cert rotation. Sidecars with unexpired certs keep running, but any pod restart or cert expiry silently breaks identity. If your trust bundle was generated by 1.18 or you manually rotated to Ed25519/RSA keys, this is a crash-loop waiting to happen. Upgrading to 1.17.7 is the only fix — no trust bundle migration needed.

• breakingScheduler etcd compaction mode change requires PVC capacity review

  The embedded etcd compaction mode switches from periodic (10 min) to revision-based (1,000,000 revisions), and the default storage size jumps from 1Gi to 16Gi. Kubernetes StatefulSet volumeClaimTemplates are immutable, so existing 1Gi PVCs are NOT automatically resized. If you're running the scheduler at any real workflow throughput, check your current PVC utilization now. If you're close to capacity, expand the PVC on the cluster before upgrading. The helm chart uses a lookup helper to avoid overwriting existing PVC sizes, but it cannot expand them for you.

• enhancementAdd workflow payload size ratio dashboards before upgrading

  Two new histograms — dapr_runtime_workflow_payload_size_ratio and dapr_runtime_workflow_activity_payload_size_ratio — report payload size as a fraction of --max-body-size. Before upgrading, set up a Prometheus alert on histogram_quantile(0.99, ...) > 0.9 so you catch workflows trending toward the 0.95 stall threshold before they freeze. This is especially useful for workflows with large activity payloads or long histories. Note: metrics are only recorded when --max-body-size is explicitly configured.

Single targeted bug fix: messages arriving during graceful shutdown or pub/sub component hot-reload no longer get silently routed to dead-letter queues.

• breakingAudit your dead-letter queues for silently lost messages

  If you run pub/sub with dead-letter queues configured, messages diverted there during past rolling deployments or restarts were never retried — they just sat in the DLQ. Before upgrading, inspect those queues for messages that should have been processed. After upgrading to 1.17.6, plan to replay or reprocess any legitimate messages found there. Going forward, monitor DLQ depth during deployments as a health signal; a spike should now indicate actual processing failures, not shutdown timing artifacts.

• enhancementUpgrade if you do rolling deployments or frequent restarts

  Any team doing Kubernetes rolling updates or frequent pod restarts with pub/sub workloads should treat this as a high-priority patch. The previous behavior was silent — no errors surfaced to your app, messages just disappeared into DLQs. The fix is low-risk (a targeted behavior change in the shutdown path), so upgrading from any 1.17.x release is straightforward.

Critical security patch fixing ACL bypass via path traversal in service invocation — any deployment using access control policies must upgrade immediately.

• securityUpgrade immediately if you use service invocation ACLs

  This is a real ACL bypass, not a theoretical one. If your Dapr deployment uses access control policies for service invocation and the Dapr API is reachable by untrusted callers — even internal ones — you are vulnerable. The gRPC vector is especially dangerous since it passes method strings raw with no sanitization. Upgrade to v1.15.14 now. There is no workaround short of disabling service invocation or isolating the Dapr API entirely.

• securityAudit who can reach your Dapr API endpoints

  This vulnerability required API access, so the blast radius depends entirely on your network posture. After upgrading, take the opportunity to review which workloads and network paths can reach the Dapr HTTP and gRPC APIs. Sidecar-only access (localhost) is the safest posture — if you're exposing Dapr APIs more broadly, tighten that regardless of this fix.

• breakingVerify your service invocation method paths still route correctly after normalization

  The fix applies path.Clean normalization to all method paths and rejects any containing #, ?, null bytes, or control characters. If any of your services legitimately use encoded slashes (%2F) as path separators in method names — particularly over gRPC where these were previously passed through raw — those calls will now behave differently. Test your service-to-service invocation patterns before rolling this to production.

v1.17.5 is a security-only patch fixing a path traversal vulnerability that allowed attackers to bypass service invocation ACL policies via encoded URL characters.

• securityUpgrade immediately if you use service invocation ACLs

  Any deployment with access control policies for service invocation is vulnerable. An attacker with Dapr API access (HTTP or gRPC) could reach denied endpoints by encoding the path. gRPC is especially risky since method strings were passed raw. Upgrade to v1.17.5 now — there is no workaround short of removing Dapr API exposure entirely. After upgrading, audit your ACL policies to confirm expected paths are actually being enforced.

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix adds strict validation: method paths containing #, ?, null bytes, or control characters are now rejected at the invocation edge. If any of your services use these characters in method paths (uncommon but possible with gRPC), those calls will fail after upgrade. Test your service invocation paths in a staging environment before rolling this to production.

Critical security fix: path traversal and encoded characters in service invocation method paths could bypass ACL policies entirely. Upgrade immediately if you use access control policies.

• securityUpgrade immediately if you use Dapr ACL policies

  Any deployment with service invocation access control policies is vulnerable. An attacker with access to the Dapr HTTP or gRPC API can craft method paths that the ACL permits but route to denied endpoints. The gRPC vector is especially dangerous since no client-side sanitization occurs. Upgrade to v1.16.14 now — there is no viable workaround short of removing Dapr API access entirely. After upgrading, audit your ACL policy rules to confirm they match the normalized path forms (resolved ../ and no encoded separators).

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix actively rejects method paths containing fragment (#), query (?), null bytes, or control characters rather than silently normalizing them. If any of your services invoke methods with these characters (unlikely but possible via programmatic gRPC calls), those calls will fail after upgrading. Review your service invocation call sites — especially any that construct method paths dynamically — before rolling this out to production.

Dapr v1.16.13 fixes a critical scheduler reliability bug affecting multi-replica deployments, patches a silent Pulsar misconfiguration that could cause OOM crashes, and rebuilds with Go 1.25.9 for security fixes.

• securityUpgrade immediately for Go 1.25.9 security patches

  This build patches vulnerabilities in Go's crypto/x509, crypto/tls, archive/tar, and html/template packages. Any Dapr deployment still on 1.16.12 or earlier is exposed. Upgrade to 1.16.13 now — there's no workaround short of rebuilding from source with Go 1.25.9 yourself.

• breakingPulsar users: processMode will now actually take effect — verify your config

  If you have processMode set in your Pulsar component YAML, it was silently ignored before this release. After upgrading, that config will be enforced. If you set processMode: sync expecting ordered processing but were actually running async, behavior changes on upgrade. Review your Pulsar component metadata and subscription behavior before rolling this out to production. Also check maxConcurrentHandlers: if it was set to 0, it previously caused a deadlock; now it falls back to 100.

• breakingMulti-replica scheduler deployments: patch this immediately

  The scheduler bug is severe in practice. A routine pod restart — due to a rolling update, OOM kill, or node eviction — would silently stop all job triggers across your deployment until some unrelated cluster event re-established connections. There's no alerting or visible failure; jobs just stop firing. If you run multiple scheduler replicas (standard HA setup), this fix is critical. Upgrade and verify your scheduled jobs are firing after any scheduler pod restart.

Dapr 1.17.4 patches seven bugs spanning workflow correctness, Pulsar OOM risk, actor freeze under placement pressure, and a Go stdlib security update. Deploy promptly if you use any of these features.

• securityUpgrade immediately for Go stdlib CVE fixes

  Go 1.25.9 patches vulnerabilities in archive/tar, crypto/tls, crypto/x509, html/template, and the compiler. All Dapr binaries and Docker images are rebuilt with the patched toolchain. Update your Dapr runtime to 1.17.4 now — no config changes needed, just the version bump.

• breakingPulsar processMode behavior has changed — validate your component config

  If you set processMode in Pulsar component YAML before this fix, it was silently ignored and you were running in default mode. After upgrading, the setting takes effect. If you had processMode: sync expecting ordered processing but were unknowingly running async, behavior will change. Also, async mode now caps concurrency at maxConcurrentHandlers (default 100). Review your Pulsar component metadata and test throughput behavior before rolling to production.

• enhancementEliminate actor/workflow freeze risk from placement slowness

  The placement dissemination freeze bug could cause cascading health check failures during rolling updates — Kubernetes would declare pods unhealthy and restart them, worsening the cycle. With 1.17.4, a slow peer triggers reconnect rather than a fatal teardown. If you've seen unexplained actor hangs or zombie daprd processes during rollouts, this is likely the cause. No configuration change needed; upgrading is sufficient.

Dapr v1.16.12 patches a gRPC auth bypass CVE, fixes broken Pulsar Avro/JSON schema handling that blocked message delivery, and resolves a Scheduler cluster stall lasting up to 20 minutes after pod restarts.

• securityUpgrade immediately to patch gRPC auth bypass (CVE-2026-33186)

  CVE-2026-33186 allows unauthorized gRPC requests to bypass authorization under certain conditions. This affects all Dapr 1.16.x versions prior to 1.16.12. Upgrade now — there's no workaround that doesn't involve patching the dependency.

• breakingPulsar Avro + CloudEvents schema registration has changed — existing topics may need attention

  If you're running Dapr 1.16.0–1.16.11 with Pulsar topics using Avro schemas and CloudEvents wrapping (the default), the schema registered in Pulsar's Schema Registry was wrong. After upgrading, new schema registrations will use the correct CloudEvents envelope Avro schema. Check whether existing Pulsar topics have mismatched schemas in the registry and whether downstream non-Dapr consumers are affected. Use the new rawSchema metadata option only for topics intentionally serving raw payloads.

• enhancementScheduler HA deployments are no longer vulnerable to 20-minute stalls on pod restart

  Any HA Dapr deployment (3 Scheduler instances) with active workflows or actor reminders was at risk of a silent 20-minute outage after a pod restart. The fix makes engine shutdown context-aware, so in-flight triggers cancel immediately and the cluster re-establishes quorum in seconds. If you've been observing unexplained workflow/reminder gaps after rolling updates or node maintenance, this is the cause. Upgrade and also note that Dapr v1.17 redesigned the trigger path entirely to avoid this class of problem.

Dapr v1.17.3 patches two CVEs (gRPC auth bypass, TIFF OOM DoS) and fixes several high-impact runtime bugs including actor response data loss over h2c, a cascading placement failure, and a scheduler silent-stop bug.

• securityUpgrade immediately for two active CVEs

  CVE-2026-33186 allows gRPC authorization bypass — unauthorized requests could reach your services. CVE-2026-33809 allows a malicious 8-byte TIFF file to trigger ~4GB memory allocation and OOM-crash a sidecar. Both are fixed only in v1.17.3. There is no workaround short of upgrading. Treat this as an urgent patch, especially if your Dapr components process any image data or expose gRPC endpoints to untrusted callers.

• breakingActor + h2c users were silently losing response data — verify your setup

  If you run actors with --app-protocol h2c, every actor method invocation since v1.17.2 could have returned HTTP 200 with an empty body. Your app received no error, just missing data. After upgrading to v1.17.3, audit any actor calls that might have been silently failing and verify response payloads are intact. If you log or cache actor responses, replay or revalidate any data collected since upgrading to v1.17.2.

• enhancementHA Scheduler deployments: restart pods after upgrade to clear stale leadership state

  The scheduler silent-stop bug left stale etcd leadership keys that block quorum convergence. After upgrading, do a coordinated restart of all Scheduler pods to force a clean leadership election. Going forward, workflow timers, scheduled jobs, and actor reminders should be reliable after rolling updates. If you previously saw reminders or jobs randomly stop firing after a Scheduler pod restart, this is the fix.

Three critical Scheduler HA bugs fixed — cascading crashes, silent partition stalls, and Windows AKS sidecar failures — plus a Go security bump to 1.25.8.

• securityGo 1.25.8 security patches — rebuild or upgrade

  Go 1.25.8 fixes vulnerabilities in html/template, net/url, and os packages. If you're running Dapr v1.16.10 or earlier, the binary was built against a patched Go version that still carries these issues. Upgrading to v1.16.11 picks up the fixed runtime automatically. If you also maintain custom Dapr-adjacent services built with Go 1.25.7, rebuild those separately.

• breakingUpgrade immediately if running Scheduler in HA mode

  Any multi-instance Scheduler deployment on v1.16.0–v1.16.10 is exposed to two distinct failure modes: a cascading crash under high job load, and a silent stall where instances hold partition leases but never fire jobs. Both require restarting all Scheduler pods to recover. Neither has a workaround short of upgrading. If you're running Dapr Workflows, actor reminders, or scheduled jobs in HA, treat this as urgent — workflows can stop firing entirely after a routine pod eviction or rolling update.

• breakingWindows AKS users: broken since v1.16.9, fixed here

  If you deployed Dapr on AKS Windows nodes between v1.16.9 and v1.16.10, your daprd sidecars have been stuck in CrashLoopBackOff. The root cause was a Docker manifest tooling change that dropped the os.version field, causing the Windows container runtime to pull the wrong image variant. Upgrading to v1.16.11 restores correct behavior — no manifest or config changes needed on your end.

Dapr v1.17.2 is a high-priority patch with three Go stdlib CVE fixes, a CRD breaking change requiring manual update, and fixes for cascading actor placement failures and streaming OOM issues.

• securityUpgrade immediately to patch three Go stdlib CVEs

  Go 1.24.x carried GO-2026-4601 (IPv6 SSRF via net/url), GO-2026-4602 (path escape via os.Root), and GO-2026-4603 (XSS via html/template). If your Dapr sidecars handle user-supplied URLs or template rendering in any adjacent service, exposure is real. Upgrade to v1.17.2 now — the fix is a Go toolchain bump, so no code changes are needed on your end.

• breakingManually update CRDs before Helm upgrade or daprd will fail to start

  The `stateRetentionPolicy` fields in the Configuration CRD changed from `type: integer` to `type: string`. Helm does not update CRDs automatically. If you run `helm upgrade` without updating the CRD first, any existing Configuration objects using duration strings will fail Kubernetes validation and daprd may fail to load its config. Run the CRD update step from the Kubernetes upgrade guide before touching Helm. If you're not using workflow state retention policies today, the risk is lower, but update the CRD anyway to stay consistent.

• enhancementLarge actor deployments and streaming workloads should prioritize this patch

  Two fixes deserve immediate attention beyond security. First, deployments with 50+ actor replicas were hitting cascading dissemination timeouts in 1.17.x — the placement service batching fix in this release resolves that. Second, any service invocation path passing large or streaming bodies (file uploads, SSE, chunked data) was silently OOM-killing sidecars by buffering everything in memory. Both are now fixed. If either pattern applies to your workload, treat this upgrade as urgent rather than routine.

Dapr 1.17.1 fixes critical runtime issues including WASM component registration failures on production architectures and workflow cleanup problems.

• breakingUpgrade immediately if using WASM components

  WASM binding and middleware components were completely broken on production architectures in v1.16.0-v1.17.0. Applications using these components failed to start. Test your WASM components after upgrading to confirm they register and function correctly.

• enhancementExpect placement service performance improvements

  Large clusters with many non-actor sidecars will see reduced placement overhead. Monitor placement service metrics and actor invocation latency—you should observe fewer lock cycles and improved performance, especially during sidecar restarts.

• enhancementReview workflow cleanup configurations

  Previously stalled workflows that became unstalled can now be properly cleaned up. Verify your state retention policies are working as expected and check for any workflow instances that should have been purged but weren't.

Dapr 1.16.10 fixes critical WASM component registration failures on production architectures and patches security vulnerabilities in Go runtime and OpenTelemetry SDK.

• securityUpdate for Go runtime and OpenTelemetry security patches

  This release patches vulnerabilities in Go 1.25.7 (crypto/tls, go command) and OpenTelemetry SDK (arbitrary code execution via PATH hijacking). Plan your upgrade within your normal security patching window, prioritizing environments where PATH manipulation is possible.

• breakingUpgrade immediately if using WASM components

  WASM binding and middleware components have been completely broken on production architectures since v1.16.0. If you're using these components and running v1.16.0-v1.16.9, upgrade to v1.16.10 immediately as your WASM components are silently failing to register.

• enhancementReview Pulsar Avro message publishing for early error detection

  Pulsar PubSub now validates JSON messages against Avro schemas before publishing, catching malformed data earlier. Test your Pulsar publishing workflows to ensure they handle the new validation errors gracefully and benefit from faster codec performance.