search

GoogleCloudPlatform / emblem

Archived: Emblem Giving is a sample application that demonstrates a serverless architecture with continuous delivery, and trouble recovery. :diamond_shape_with_a_dot_inside:
Apache License 2.0
239 stars 61 forks source link

Bug: Resolve bug that is possibly preventing trace ID propagation on viewing donations #625

Open pattishin opened 2 years ago

pattishin commented 2 years ago

Full context from @ace-n: Update: I tried to get trace ID propagation working for both POST /donate and GET /viewDonations. I was able to specify the X-Cloud-Trace-Context header in the response, but this has no effect on the request's actual trace ID (as recorded by Cloud Logging).

Related PR: https://github.com/GoogleCloudPlatform/emblem/pull/620

grayside commented 2 years ago

I responded to this comment in the PR. I believe this problem is rooted in a misinterpretation that we're trying to set a trace ID in a response, as opposed to extract the request trace ID and make it available for frontend UI building.

ace-n commented 2 years ago

There are two requests here:

  1. a POST to /donate to submit the donation
  2. a GET [redirect] to /viewDonation to view the resulting donation

Currently, #620 only shows the first request (POST /donate) and omits the second (GET /viewDonation).

We could call this intended behavior, but I'm assuming our end-users would prefer to see the entire request chain.

grayside commented 2 years ago

Interesting, so the issue here is that by using a redirect in donate, we are splitting the full transaction. In a more dynamic UI, we would maybe get the confirmation without leaving the page and viewDonation would be outside this journey.

muncus commented 2 years ago

Trace data is really not designed to be reused between requests. It is possible to do this by having the frontend generate trace IDs to send with multiple requests, but I've only heard of that approach being taken with native (non-web) apps. (i'm also not sure that all trace backends would support non-overlapping spans).

Generally, i'd discourage any manual manipulation of trace headers, and let the OTel SDK do that for us, but i suppose that ball is already in my court 😅