pubsub: "Operation attempted on ended Span" when a modack is flushed after the message was acked
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 82/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- node.js, typescript
- Lĩnh vực
- backend, observability
Hướng nghiên cứu
Đọc handwritten/pubsub/src/telemetry-tracing.ts ở phần quanh createAckRpcSpan và createModackRpcSpan, sau đó kiểm tra luồng hàng đợi được mô tả trong handwritten/pubsub/src/message-queues.ts và subscriber.ts. Tái hiện trường hợp span đã kết thúc bằng gist được liên kết hoặc một bài kiểm thử tập trung tương đương. Hoàn tất khi tracing ack và modack tránh gọi các phương thức trên span đã kết thúc và bài kiểm thử xác nhận SDK không còn ghi nhật ký lỗi đó.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Please make sure you have searched for information in the following guides.
- Search the issues already opened: https://github.com/GoogleCloudPlatform/google-cloud-node/issues
- Check the API's issue tracker (related, but publisher-side only: googleapis/nodejs-pubsub#2110, googleapis/nodejs-pubsub#2119)
Library Name
@google-cloud/pubsub (reproduced on 6.0.1 and 6.4.1)
A screenshot that you have tested with "Try this API".
N/A. This is a client-side bug in the library's OpenTelemetry instrumentation. No API call is needed to reproduce it.
Link to the code that reproduces this issue. A link to a public Github Repository or gist with a minimal reproduction.
https://gist.github.com/tmair/b9c1cd2b558e40eb8423566580d0a244
A step-by-step description of how to reproduce the issue, based on the linked reproduction.
npm install && npm start- The repro registers an SDK
BasicTracerProvider, enables pubsub tracing, starts a subscribe span and ends it. This simulates a message that was acked while a modack for it was still queued. It then callsPubsubSpans.createModackRpcSpan([subscribeSpan], ...), which is whatModAckQueue._sendBatchdoes when the queue flushes. - The OpenTelemetry SDK logs:
Cannot execute the operation on ended Span {traceId: ..., spanId: ...} Error: Operation attempted on ended Span {traceId: ..., spanId: ...}
at SpanImpl._isSpanEnded (.../@opentelemetry/sdk-trace/build/src/Span.js:342:27)
at SpanImpl.addLink (.../@opentelemetry/sdk-trace/build/src/Span.js:170:18)
at .../@google-cloud/pubsub/build/src/telemetry-tracing.js:421:23
at Array.forEach (<anonymous>)
at PubsubSpans.createModackRpcSpan (...)
We see this in production on a subscriber created with enableOpenTelemetryTracing: true and @opentelemetry/sdk-node (sdk-trace 2.11.0). It happens for messages whose processing takes long enough to get a lease extension. The stack trace from production:
Error: Operation attempted on ended Span {traceId: 8d525b04ad08368f161db86c3d9c950d, spanId: 6419191f508e8c82}
at SpanImpl._isSpanEnded (/app/otel-instrumentation/node_modules/@opentelemetry/sdk-trace/build/src/Span.js:342:27)
at SpanImpl.addLink (/app/otel-instrumentation/node_modules/@opentelemetry/sdk-trace/build/src/Span.js:170:18)
at /app/node_modules/@google-cloud/pubsub/build/src/telemetry-tracing.js:420:23
at Array.forEach (<anonymous>)
at PubsubSpans.createModackRpcSpan (/app/node_modules/@google-cloud/pubsub/build/src/telemetry-tracing.js:418:26)
at /app/node_modules/@google-cloud/pubsub/build/src/message-queues.js:538:54
at Array.map (<anonymous>)
at ModAckQueue._sendBatch (/app/node_modules/@google-cloud/pubsub/build/src/message-queues.js:533:57)
at async ModAckQueue.flush (/app/node_modules/@google-cloud/pubsub/build/src/message-queues.js:262:29)
A clear and concise description of what the bug is, and what you expected to happen.
The ack and modack queues flush independently, but both keep a reference to the message's subscribe span:
- The lease manager extends the deadline of a message that is still being processed.
MessageQueue.addstoresmessage.parentSpanastracingSpanin the modack batch (message-queues.ts#L254). - The handler calls
message.ack().Subscriber.ackwaits only for the ack queue to flush and then callsmessage.endParentSpan()(subscriber.ts#L889-L892). - The modack queue flushes afterwards.
createModackRpcSpancallsm.addLink(...)on the subscribe span that has already ended (telemetry-tracing.ts#L602-L608).
The OpenTelemetry SDK rejects the addLink call and logs an error through diag. Nothing is thrown and the messages are acked correctly, but every affected message produces an error log entry, which shows up as an error group in Cloud Error Reporting. createAckRpcSpan uses the same pattern (telemetry-tracing.ts#L554-L560) and could hit the same problem for a span that ended in another way (e.g. nack or shutdown).
Expected: the library does not call methods on spans that it has already ended, so no errors are logged.
Suggested fix: skip spans that are no longer recording in createModackRpcSpan and createAckRpcSpan:
messageSpans.forEach(m => {
if (m && isSampled(m) && m.isRecording()) {
m.addLink({context: span.spanContext()});
}
});
An SDK span returns isRecording() === false once it has ended, so this skips exactly the failing case. The link from the subscribe span to the RPC span is lost for those messages, but the subscribe span has already been exported at that point anyway.
A clear and concise description WHY you expect this behavior, i.e., was it a recent change, there is documentation that points to this behavior, etc. **
The OpenTelemetry specification does not allow changes to a span after end() has been called ("Implementations SHOULD ignore all subsequent calls to End and any other Span methods"), and the SDK reports such calls as errors. The library ends the subscribe span itself in Subscriber.ack, so it should not modify that span afterwards. The same class of bug was reported for the publisher side in googleapis/nodejs-pubsub#2110 and googleapis/nodejs-pubsub#2119.
- Ngôn ngữ chính
- TypeScript
- Star
- 3.2k
- Fork
- 732
- Merge trung bình
- 3 ngày 7 giờ
- Pull request đã merge (30 ngày)
- 117
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của googleapis/google-cloud-node
-
Broken deprecation chainĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
googleapis/google-cloud-node#9854 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
storage: V4 getSignedUrl sorts canonical headers with localeCompare, so they disagree with X-Goog-SignedHeadersCó thể đã có người làm @itsrayeedscodespace đã nhận 6 ngày trước. Đang mởapi: storage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
googleapis/google-cloud-node#9840 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
firestore: getPartitions() emits gax AutopaginateTrueWarning in every processCó thể đã có người làm @TheRealDanii đã nhận 9 ngày trước. Đang mởapi: firestore
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
googleapis/google-cloud-node#9736 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
googleapis/google-cloud-node#9723 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
spanner: requiring @google-cloud/spanner stops the process from exiting on SIGTERM/SIGINTCó thể làm lại được @alkatrivedi đã nhận 31 ngày trước và không có pull request nào đang mở. Đang mởapi: spanner
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
googleapis/google-cloud-node#9513 · 1 reaction · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của googleapis/google-cloud-node
Issue tương tự
-
bug UI
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
wardian-app/Wardian#1746 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area: interop area: sip-core v3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
fonoster/routr#705 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster no-stale P2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
openclaw/openclaw#198551 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày