Commit ca41414
Fix background-task silent failures in PublishSubscribeReceiver
The initial fix for #1663 addressed the synchronous subscribe path but left a
near-identical silent-failure hole in the background continuation path:
HandleTaskCompletion was an async Task wired via _ = ContinueWith(...), so when
no ErrorHandler was configured its "throw daprException" faulted an unobserved
inner Task that never surfaced — exactly the bug the PR set out to fix.
Changes:
- HandleTaskCompletion no longer throws. It caches the first fault per subscribe
cycle in a new pendingBackgroundFault field, which the next SubscribeAsync
call drains and rethrows. Callers that skip the ErrorHandler still observe
the error reliably rather than losing it to unobserved-task-exception void.
- A new hasFaulted dedupe flag ensures that when multiple sibling continuations
(FetchDataFromSidecar / ProcessAcknowledgementChannel / ProcessTopicChannel)
all fault on a single sidecar outage, only the first is reported.
- ResetStreamStateAsync now acquires the same semaphore used by GetStreamAsync,
nulls clientStream before resetting hasInitialized, and disposes the prior
stream — closing the race where a concurrent SubscribeAsync could observe a
stale clientStream and leaking the gRPC streaming call on reset.
- OperationCanceledException handling now inspects every inner exception (via
AggregateException.InnerExceptions.All(...)) instead of just the first, so a
fault wrapping both an OCE and a real RpcException still surfaces the real
error.
- When the user-supplied ErrorHandler itself throws, both the original fault
and the handler failure are combined into an AggregateException and cached,
replacing the previous empty catch that silently swallowed handler bugs.
- DaprSubscriptionOptions.ErrorHandler and SubscriptionErrorHandler XML docs
updated to describe the new cache-and-rethrow contract accurately.
Tests:
Five new tests drive the real SubscribeAsync -> ContinueWith -> HandleTaskCompletion
chain (instead of awaiting HandleTaskCompletion directly) to reproduce each
scenario end-to-end:
- NextSubscribeRethrows — verifies the no-handler cache path
- InvokesErrorHandlerExactlyOnce — verifies hasFaulted dedupe
- NextSubscribeRecreatesStream — verifies reset + retry works end-to-end
- BackgroundFetchCancelled_DoesNotCachePendingFault — verifies OCE short-circuit
- ErrorHandlerThrows_CachesCombinedFaultForNextSubscribe — verifies handler-fault capture
I verified these five reproduce the bug: after temporarily reverting the source
fix and re-running them, they all fail (with the exact "background fault was
not cached" / synchronous-throw symptoms the fix addresses).
Two pre-existing unit tests were adjusted to match the new contract — they now
exercise HandleTaskCompletion followed by SubscribeAsync to confirm the fault
is surfaced via the cache-and-rethrow path instead of via a synchronous throw.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: George Tsiokos <george@tsiokos.com>1 parent 0092cda commit ca41414
4 files changed
Lines changed: 379 additions & 25 deletions
File tree
- src/Dapr.Messaging/PublishSubscribe
- test/Dapr.Messaging.Test/PublishSubscribe
Lines changed: 4 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
44 | 44 | | |
45 | 45 | | |
46 | 46 | | |
47 | | - | |
| 47 | + | |
| 48 | + | |
| 49 | + | |
| 50 | + | |
48 | 51 | | |
49 | 52 | | |
50 | 53 | | |
| |||
Lines changed: 86 additions & 10 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
74 | 74 | | |
75 | 75 | | |
76 | 76 | | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
| 81 | + | |
| 82 | + | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
77 | 88 | | |
78 | 89 | | |
79 | 90 | | |
| |||
82 | 93 | | |
83 | 94 | | |
84 | 95 | | |
| 96 | + | |
| 97 | + | |
| 98 | + | |
85 | 99 | | |
86 | 100 | | |
87 | 101 | | |
| |||
113 | 127 | | |
114 | 128 | | |
115 | 129 | | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
| 136 | + | |
| 137 | + | |
116 | 138 | | |
117 | 139 | | |
118 | 140 | | |
119 | 141 | | |
120 | 142 | | |
121 | 143 | | |
| 144 | + | |
| 145 | + | |
| 146 | + | |
122 | 147 | | |
123 | 148 | | |
124 | 149 | | |
| |||
168 | 193 | | |
169 | 194 | | |
170 | 195 | | |
171 | | - | |
| 196 | + | |
| 197 | + | |
172 | 198 | | |
| 199 | + | |
| 200 | + | |
| 201 | + | |
| 202 | + | |
| 203 | + | |
| 204 | + | |
| 205 | + | |
173 | 206 | | |
174 | 207 | | |
175 | 208 | | |
176 | 209 | | |
177 | 210 | | |
178 | 211 | | |
179 | 212 | | |
180 | | - | |
181 | | - | |
182 | | - | |
| 213 | + | |
| 214 | + | |
| 215 | + | |
| 216 | + | |
| 217 | + | |
| 218 | + | |
183 | 219 | | |
184 | | - | |
| 220 | + | |
185 | 221 | | |
186 | | - | |
| 222 | + | |
| 223 | + | |
| 224 | + | |
187 | 225 | | |
| 226 | + | |
188 | 227 | | |
189 | 228 | | |
190 | 229 | | |
| 230 | + | |
| 231 | + | |
| 232 | + | |
| 233 | + | |
| 234 | + | |
| 235 | + | |
191 | 236 | | |
192 | 237 | | |
193 | 238 | | |
194 | 239 | | |
195 | 240 | | |
196 | 241 | | |
197 | | - | |
| 242 | + | |
| 243 | + | |
| 244 | + | |
| 245 | + | |
| 246 | + | |
| 247 | + | |
| 248 | + | |
| 249 | + | |
198 | 250 | | |
| 251 | + | |
| 252 | + | |
| 253 | + | |
| 254 | + | |
| 255 | + | |
| 256 | + | |
| 257 | + | |
| 258 | + | |
| 259 | + | |
| 260 | + | |
199 | 261 | | |
| 262 | + | |
| 263 | + | |
| 264 | + | |
| 265 | + | |
| 266 | + | |
| 267 | + | |
| 268 | + | |
| 269 | + | |
| 270 | + | |
| 271 | + | |
| 272 | + | |
200 | 273 | | |
201 | 274 | | |
202 | | - | |
| 275 | + | |
| 276 | + | |
| 277 | + | |
| 278 | + | |
203 | 279 | | |
204 | | - | |
| 280 | + | |
205 | 281 | | |
206 | | - | |
| 282 | + | |
207 | 283 | | |
208 | 284 | | |
209 | 285 | | |
| |||
Lines changed: 2 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
19 | 19 | | |
20 | 20 | | |
21 | 21 | | |
22 | | - | |
| 22 | + | |
| 23 | + | |
23 | 24 | | |
24 | 25 | | |
0 commit comments