Help with springboot and datadog GCP pubsub

@techplusintl

Hi, To ensure the dd.trace_id propagates correctly from artifact A to artifact B, I'll implement the necessary changes to the pubsub message and MDC. I have experience working with Spring Boot and Java, which will help me address the issues you're facing. Ready to start once you provide any additional details or access needed to the artifacts.

@ParasTech7

I have 21 years of experince, Principal Software engineer at Microsoft, I have extensive experince with data spring boot, JPA, Java 17 and 21, data integration, API development and development microservices, well versed with sql based databases . Experince of building and designing distributed system softwares with tools like apache flink and kakfa. I have understood your project and can help you with it.

@Herculesz

Hi I have solid experience with Java, Spring Boot, distributed tracing, async messaging, Google Pub/Sub, and log correlation across multi-service systems. The core issue here is that dd.trace_id is being manually injected into MDC, but MDC is thread-local and often gets lost or replaced when execution moves across async consumers, worker threads, or new tracing scopes in artifact B. I can help trace where the context is breaking, review how artifact A publishes the trace metadata, and fix propagation in artifact B so logs stay correlated with the same Datadog trace through the full processing flow. This usually requires checking Datadog tracer behavior, Pub/Sub consumer threading, MDC lifecycle, and whether the logging context is being overwritten after the first few log statements. I can also review the current instrumentation approach and replace fragile manual propagation with a cleaner context propagation strategy tied to the message consumer lifecycle. My focus would be to make trace continuity reliable across both artifacts, not just for a few logs, but for the full transaction path from publisher to subscriber. This is the kind of Spring Boot observability/debugging work I’m comfortable handling at code and runtime level. Thanks, Hercules

@akshayatm

Greetings of the day. Hi Sir, I am an experienced software developer expert in gcp, gke , kubernetes , microservices , spring boot, REST API, Soap. I understood your issue. I have recently worked on these kind of issues. You’re likely only passing dd.trace_id via Pub/Sub and setting it in MDC. MDC is probably not the actual source of tracing, so Datadog may override it with a new trace context. That’s why initial logs often show the correct trace_id, but later logs tend to switch. The issue is most likely due to missing full context propagation (parent-id, sampling-priority).

@usmanbashir12100

Hi, I’ve worked with Spring Boot and Datadog tracing, including Pub/Sub-based microservices where proper trace propagation is critical. The issue you’re facing is due to relying on MDC instead of propagating and activating the full trace context. I can help you correctly implement context injection in Service A and extraction/activation in Service B so the same trace_id is preserved across all logs and spans. I’ll ensure your tracing works consistently even with async processing and provide a clean, maintainable solution aligned with Datadog best practices. Happy to jump in and fix this quickly.

@juanjosec63

Hi, I have strong experience in Java, Spring Boot, distributed tracing (Datadog), and debugging context propagation issues across services using MDC and async messaging systems like Pub/Sub. I can analyze both artifacts, identify why the dd.trace_id is not consistently preserved (likely due to thread context loss or async execution), and implement a reliable propagation strategy so the trace remains consistent across all logs in service B. You can expect clear communication, fast debugging, and a clean fix that aligns with best practices for tracing and logging in distributed systems. Best regards, Juan

@giaphung2k1

Hello Experienced in Spring Boot, Datadog, and GCP Pub/Sub. I can help integrate and optimize Datadog monitoring for your two existing Spring Boot artifacts. Let's ensure robust observability, including Pub/Sub interactions, is fully configured. Ready to discuss your setup and quickly define next steps. Giáp Văn Hưng

@sf264

Hello, I have understood your project goal. I would love to discuss the requirements in more detail via chat. Let's get started, Fahad.

@asimaarbi

I have solid experience working with Pub/Sub systems and message-based architectures, including handling trace propagation and logging across services. I can help ensure consistent `dd.trace_id` propagation between your Spring Boot artifacts and resolve the MDC inconsistency issue in your logs. I’ve handled similar scenarios before and can quickly identify and fix the root cause.

@techsty2014

Hi, I will fix the Datadog trace propagation between your two Spring Boot services over GCP Pub/Sub. The goal is to have Artifact B carry the same dd.trace_id from Artifact A consistently across all logs, not just the first few. The issue is almost certainly that the Datadog tracer in Artifact B is creating a new active span after initial message processing, which overwrites the MDC trace ID you injected. Instead of setting the MDC manually, I will use the Datadog SDK to create a child span from the propagated trace context. This keeps the trace ID consistent because the tracer itself manages the MDC rather than your code competing with it. Questions: 1) Which Datadog tracer version are you running on both artifacts? 2) Are you using Spring Cloud GCP for the Pub/Sub listener, or a custom subscriber? Let us discuss via chat.

@jeanpatrickr8

Hello, I hope this message finds you well. I understand that you need assistance with two Spring Boot artifacts, specifically regarding the propagation of the `dd.trace_id` through Pub/Sub messages to ensure consistent logging across your services. With extensive experience in Spring Boot and distributed tracing, I am well-equipped to help you achieve your goals. I have worked on similar projects where I successfully implemented tracing across microservices, ensuring that trace IDs are consistently propagated and logged. To address your requirements, I propose the following approach: - Analyze the existing setup of both artifact A and artifact B to understand the message flow and logging mechanisms. - Implement a solution to inject the `dd.trace_id` into the MDC for logging, ensuring it is consistently maintained across all logs. - Conduct thorough testing to confirm that the trace ID is propagated correctly through multiple logs, addressing any discrepancies that may arise. - Provide documentation and support for future maintenance of the tracing implementation. I am eager to begin this project and confident that I can deliver quality results on time. Please feel free to reach out if you have any questions or would like to discuss further details.

@ianb65

Hello, I’ve worked with **Spring Boot + Pub/Sub + Datadog tracing**, and I understand exactly the issue you’re facing. What’s happening is that putting `dd.trace_id` into **MDC** alone is not enough—MDC is thread-local and gets lost when execution moves across threads (which is very common in async processing, Pub/Sub listeners, or executors). That’s why you see correct IDs in some logs and then different ones later. To fix this properly, you need to **propagate the Datadog trace context**, not just copy the trace_id manually. My approach: • Extract full trace context (`x-datadog-trace-id`, `x-datadog-parent-id`, etc.) from Pub/Sub message attributes • Recreate the trace in service B using Datadog APIs (not just MDC) • Ensure context propagation across threads (executor / async config) • Align logging so MDC reflects the active trace consistently I can review both artifacts and fix the propagation so the **same trace_id is preserved end-to-end across services and all logs**. This is a common issue with async + MDC, and I can resolve it cleanly. Ready to check your code and patch it quickly.

@billybryan98

Hello there, I hope you’re well. I’m an independent Java/Spring Boot engineer with hands-on experience building and debugging distributed traces across microservices. I’ve worked with Datadog tracing, Google Pub/Sub in GCP, and Spring Boot apps to propagate trace context across services, ensuring log correlation stays intact from A to B. From your setup, I’ll implement consistent dd.trace_id propagation by injecting the value into the MDC in artifact A and carrying it through the Pub/Sub attributes to artifact B. I’ll verify the correlation by instrumenting every receive path and logging the trace_id consistently, then fix any MDC synchronization issues so each subsequent log retains the correct dd.trace_id. I’ll use standard Spring Boot beans, Cloud Pub/Sub adapters, and Datadog tracing integration to minimize risk and maximize observability, without relying on outside links. I can handle this end-to-end based on my experience and your architecture. I’ll deliver a tested solution with clear traces and minimal disruption. Best regards, Billy Bryan

@mahads31

As an experienced and dedicated freelance web and software developer, I am well-equipped to tackle the challenges presented by your current project. I understand the importance of traceability and reliability when it comes to complex system architectures like yours. Having worked with different industries and various technologies, I'm particularly skilled in Spring Boot, DataDog GCP PubSub, and log management systems. My innovative-first approach means I never settle for "good enough". Rather, I am committed to crafting well-designed solutions that are scalable, efficient and purposeful - aligning perfectly with your goal of maintaining a consistent `dd.trace_id`. My proven ability to not just deliver results but to also understand broader business objectives promises to keep your project on target.

@johnedwardl

Hi, I will ensure that the dd.trace_id is consistently propagated from artifact A to artifact B in your Spring Boot applications. The issue with the varying trace IDs in the logs suggests a problem with the context management during the message handling process. My experience with Spring Boot and distributed tracing will allow me to quickly identify and resolve the root cause. I'll implement a solution that maintains the trace context in the MDC throughout the lifecycle of your pub/sub messages. This will involve ensuring that the trace ID is correctly set upon message reception and remains stable for all subsequent log entries. To optimize this, I’ll review your existing implementation in artifact B, focusing on how the message attributes are processed and logged. Are there any specific logging frameworks you prefer? Also, do you have any preferred metrics for measuring the impact of this change? Let’s solve this efficiently. Thank you.

@emilesd617

Hi, I am a backend developer with 8 years of experience working with Java, Spring Boot, GCP Pub/Sub, Datadog tracing, and distributed systems. For this project, the main issue is trace context not being propagated correctly across async Pub/Sub flow, especially with MDC losing the dd.trace_id between logs. I will fix this by implementing proper Datadog trace context propagation and ensuring consistent context handling across threads and message processing so logs stay linked end-to-end. I'm an individual freelancer and can work on any time zone you want. Please contact me with the best time for you to have a quick chat. Looking forward to discussing more details. Thanks. Emile.

@rogelitoc

Hello, In my opinion, the problem of this project is that the trace ID propagation across artifacts is inconsistent, leading to log discrepancies. I will implement a centralized logging configuration using SLF4J with MDC to ensure that the trace ID from the pubsub message is consistently injected into all log entries throughout the application lifecycle. The pubsub message will be parsed in artifact B to extract the trace ID, which will then be set in the MDC before processing the logs. I will ensure that the MDC context is cleared appropriately to handle edge cases and prevent trace ID leakage. The deliverable will be a robust logging mechanism in artifact B that captures and maintains the correct trace ID across all log statements, with comprehensive unit tests to verify consistency. My background includes extensive experience with Spring Boot and distributed tracing mechanisms. I can start immediately. Regards.

@amadorjay

Hello, The primary challenge here is ensuring consistent propagation of the `dd.trace_id` across the pub/sub architecture. Maintaining this traceability while switching between services can introduce complexities in logging and monitoring. Additionally, managing the context in which the trace ID is injected into the MDC may lead to discrepancies in logs if not handled correctly. Could you clarify how the existing logging framework is set up in artifact B? Specifically, what mechanisms are currently in place for managing the MDC? Furthermore, are there specific scenarios where the trace ID is lost, or does this happen consistently across all logs? Looking forward to understanding the nuances of your system's architecture.

@cindyviorinar

Hi there, I read your description and reviewed the issue: artifact A sends a Pub/Sub message with dd.trace_id in attributes, artifact B reads it and injects into MDC but later logs show a different dd.trace_id. I can help stabilize trace propagation across your Spring Boot services. I’ve implemented distributed-tracing fixes for Java services using Datadog and Pub/Sub. The likely causes are: a new span being created in Artifact B that overwrites the trace id, MDC not being propagated across async threads/executor, or Datadog tracer starting fresh traces when context isn’t restored. My approach: review Artifact B’s subscriber code, verify you extract dd.trace_id and dd.span_id and set the Datadog trace context (using the tracer API or W3C/Datadog headers) before starting work, wrap executors/async callbacks to propagate MDC, and ensure no automatic tracer initialization starts new root spans. I’ll provide a small patch and a test to reproduce and validate propagation. I can deliver a review and fixes in an initial 3-5 day sprint with a follow-up validation run. Which exact Pub/Sub attribute keys are you setting for trace propagation (e.g., dd.trace_id, dd.span_id, x-datadog-trace-id), and does Artifact B create any new spans before you restore the incoming trace context? Best regards, Cindy Viorina