feat(cloudflare): Split alarms into multiple traces and link them#19373
feat(cloudflare): Split alarms into multiple traces and link them#19373
Conversation
JPeer264
changed the title
Codecov Results 📊Generated by Codecov Action |
size-limit report 📦
|
JPeer264
force-pushed
the
jp/split-alarm
branch
from
66f0030 to
b949de1
Compare
JPeer264
force-pushed
the
jp/split-alarm
branch
from
b949de1 to
ce3a761
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| const attributes = { | ||
| [SEMANTIC_ATTRIBUTE_SENTRY_OP]: wrapperOptions.spanOp || 'function', | ||
| [SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN]: 'auto.faas.cloudflare.durable_object', | ||
| }; |
There was a problem hiding this comment.
Default spanOp changes behavior for webSocket methods
Medium Severity
The refactoring changed span attribute assignment from conditional (only when spanOp is provided) to unconditional with a default of 'function'. This unintentionally affects webSocketMessage, webSocketClose, and webSocketError in durableobject.ts, which don't pass spanOp. Previously their spans had no sentry.op or sentry.origin attributes; now they get op: 'function' and origin: 'auto.faas.cloudflare.durable_object'. The 'function' op isn't semantically correct for WebSocket event handlers.
Additional Locations (1)
| }; | ||
| await originalStorage.put(getTraceLinkKey(methodName), storedContext); | ||
| } | ||
| } |
There was a problem hiding this comment.
Missing error handling in storeSpanContext causes user-visible failures
Medium Severity
storeSpanContext lacks try-catch around the originalStorage.put() call, unlike its counterpart getStoredSpanContext which wraps its read in try-catch. In instrumentDurableObjectStorage, storeSpanContext is called after setAlarm already succeeded. If the internal storage write fails (e.g., quota limit), the error propagates to user code, making a successful setAlarm call appear to fail. The same issue applies to storeContextIfNeeded calls in wrapMethodWithSentry, where a storage failure after a successful alarm handler would cause the alarm to appear to throw.
Additional Locations (1)
1 participant
closes #19105
closes JS-1604
closes #19453
closes JS-1774
This actually splits up alarms into its own traces and binding them with span links. It also adds the
setAlarm,getAlarmanddeleteAlarminstrumentation, which is needed to make this work.The logic works as following. When
setAlarmis getting called it will store the alarm inside the durable object. Once thealarmis being executed the previous trace link will be retrieved viactx.storage.getand then set as span link. Using the durable object itself as storage between alarms is even used on Cloudflare's alarm page.Also it is worth to mention that only 1 alarm at a time can happen, so it is safe to use a fixed key for the previous trace. I implemented the trace links, so they could be reused in the future for other methods as well, so they are not exclusively for alarms.