fix: Remove .getTraceData() from headers

[JPeer264]

👋

I'm writing / creating the PR because you opened the ticket 173143 (reference: getsentry/sentry#106855 (comment)). I was looking at your issue and saw that Sentry.getTraceData() was set manually. This is actually not needed and removed it - now it works.

So the problem now is that it should have worked fine with the additional data, but it seems that we might have a bug there if this is set twice (because we already instrument the fetch API and add the headers, so you don't have to).

This is how it looks like for me locally (the error is intended, as I haven't set up resend):

I will create a bug ticket on our side and reference this PR, so there is a backlink.

[pawelgrzybek]

Wow, soo all this was that simple? WOW, let me merge this one and confirm that here in a moment.

[JPeer264]

Can you already confirm if that worked out on your tenant as well?

[pawelgrzybek]

I'm so sorry @JPeer264 allow me one more day and I'll come back to you. So sorry for the dalay, just wanted you to know how much I apreciate your help on this one.

[JPeer264]

Absolutely no hurries from my side.

No worries, I'm here to help 🤗

[pawelgrzybek]

Hey @JPeer264 so I spent some time on this one, and I think there is still some issue, and I believe the issue is on the sentry integration plugin side of things. Let me summarise what I found, what works great and what doesn't.

---

When all is set up locally, this all working great. To summarise (simplified version):

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project and the sentry headers are carried over to the Astro action which calls external API.
3. The external API receives a request and all sentry headers with it. Along the way the same trace id headers are carries a that procuces a nice trace view with spans from multiple services combiner into one.

Here is a secreenshot that presents traced created by sentry in the browser, the same one carried over to the action and the same one used on the api.

And the example how spans from multiple services are nicely connected into the same trace. Pretty much how you got it.

---

Unfortunately it doesn't behave in the same way on production. Here is how it works on production.

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project but headers are not carried over to the Astro action scope. So the API call sent from the action does not contain headers to chain the tracing spans.
3. The external API receives a request but it is also missing the sentry heaeders as they have never been sent from the Astro action.

Here is the equivalent screenshot with the trace id produced on the browser, then lost on the action and missing on the API. Instead of screenshots from the locally running services, these are logs from the cloudflare workers.

---

Potentially there is still some issue with my tracingTarget configuration. But I think there may also be some issue on the sentry astro integration plugin, because on non-localhost env headers are not passed along to the action.

Please let me know if I can provide any extra information to help Sentry team diagnose this. I will really appreciate if we could work on that together.

[JPeer264]

Thanks for taking a closer look on this. I also just took a look. It seems that Astro is running on Cloudflare Workers in this case instead of Cloudflare Pages (the old way of Cloudflare Pages) - which means that this is a new territory, which we didn't cover yet.

It is amazing that you are already running on Cloudflare Workers and that you've discovered that, but I'm afraid that your backend code is not instrumented at all - in other words, you can't do something right now.

The good news: I played around already with the SDK and got a working draft locally. I try to push this further next week and try to make it production ready. I'll create a ticket for it and link it here as a reference.

[pawelgrzybek]

This all makes perfect sense now. This is what I call good collaboration @JPeer264, you helped me identify incorrect configuration on my project, and I helped you to identify a missing feature. Love it ❣️

Since Astro and Cloudflare married recently, I would expect more and more folks are going to use combo of Astro + Workers instead of Astro + CF Pages. Also, using workers is an official recommendation by CF team for all Astro projects now. I think it makes sense for Sentry team to add this integration at this point.

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project (nn1.dev is a low risk project, this is just a meetup page and no-one is gonna die if something goes wrong).

For now, have a fab weekend 👋

[JPeer264]

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project

I highly appreciate your help on this one. It is also a huge help that your project is open source (kudos for that), which helped initially with finding the issue. I hope I can get something out tomorrow or the day after, I can tell you more then 🥳

[JPeer264]

👋

I'm writing / creating the PR because you opened the ticket 173143 (reference: getsentry/sentry#106855 (comment)). I was looking at your issue and saw that Sentry.getTraceData() was set manually. This is actually not needed and removed it - now it works.

So the problem now is that it should have worked fine with the additional data, but it seems that we might have a bug there if this is set twice (because we already instrument the fetch API and add the headers, so you don't have to).

This is how it looks like for me locally (the error is intended, as I haven't set up resend):

I will create a bug ticket on our side and reference this PR, so there is a backlink.

[pawelgrzybek]

Wow, soo all this was that simple? WOW, let me merge this one and confirm that here in a moment.

[JPeer264]

Can you already confirm if that worked out on your tenant as well?

[pawelgrzybek]

I'm so sorry @JPeer264 allow me one more day and I'll come back to you. So sorry for the dalay, just wanted you to know how much I apreciate your help on this one.

[JPeer264]

Absolutely no hurries from my side.

No worries, I'm here to help 🤗

[pawelgrzybek]

Hey @JPeer264 so I spent some time on this one, and I think there is still some issue, and I believe the issue is on the sentry integration plugin side of things. Let me summarise what I found, what works great and what doesn't.

---

When all is set up locally, this all working great. To summarise (simplified version):

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project and the sentry headers are carried over to the Astro action which calls external API.
3. The external API receives a request and all sentry headers with it. Along the way the same trace id headers are carries a that procuces a nice trace view with spans from multiple services combiner into one.

Here is a secreenshot that presents traced created by sentry in the browser, the same one carried over to the action and the same one used on the api.

And the example how spans from multiple services are nicely connected into the same trace. Pretty much how you got it.

---

Unfortunately it doesn't behave in the same way on production. Here is how it works on production.

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project but headers are not carried over to the Astro action scope. So the API call sent from the action does not contain headers to chain the tracing spans.
3. The external API receives a request but it is also missing the sentry heaeders as they have never been sent from the Astro action.

Here is the equivalent screenshot with the trace id produced on the browser, then lost on the action and missing on the API. Instead of screenshots from the locally running services, these are logs from the cloudflare workers.

---

Potentially there is still some issue with my tracingTarget configuration. But I think there may also be some issue on the sentry astro integration plugin, because on non-localhost env headers are not passed along to the action.

Please let me know if I can provide any extra information to help Sentry team diagnose this. I will really appreciate if we could work on that together.

[JPeer264]

Thanks for taking a closer look on this. I also just took a look. It seems that Astro is running on Cloudflare Workers in this case instead of Cloudflare Pages (the old way of Cloudflare Pages) - which means that this is a new territory, which we didn't cover yet.

It is amazing that you are already running on Cloudflare Workers and that you've discovered that, but I'm afraid that your backend code is not instrumented at all - in other words, you can't do something right now.

The good news: I played around already with the SDK and got a working draft locally. I try to push this further next week and try to make it production ready. I'll create a ticket for it and link it here as a reference.

[pawelgrzybek]

This all makes perfect sense now. This is what I call good collaboration @JPeer264, you helped me identify incorrect configuration on my project, and I helped you to identify a missing feature. Love it ❣️

Since Astro and Cloudflare married recently, I would expect more and more folks are going to use combo of Astro + Workers instead of Astro + CF Pages. Also, using workers is an official recommendation by CF team for all Astro projects now. I think it makes sense for Sentry team to add this integration at this point.

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project (nn1.dev is a low risk project, this is just a meetup page and no-one is gonna die if something goes wrong).

For now, have a fab weekend 👋

[JPeer264]

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project

I highly appreciate your help on this one. It is also a huge help that your project is open source (kudos for that), which helped initially with finding the issue. I hope I can get something out tomorrow or the day after, I can tell you more then 🥳

[JPeer264]

👋

I'm writing / creating the PR because you opened the ticket 173143 (reference: getsentry/sentry#106855 (comment)). I was looking at your issue and saw that Sentry.getTraceData() was set manually. This is actually not needed and removed it - now it works.

So the problem now is that it should have worked fine with the additional data, but it seems that we might have a bug there if this is set twice (because we already instrument the fetch API and add the headers, so you don't have to).

This is how it looks like for me locally (the error is intended, as I haven't set up resend):

I will create a bug ticket on our side and reference this PR, so there is a backlink.

[pawelgrzybek]

Wow, soo all this was that simple? WOW, let me merge this one and confirm that here in a moment.

[JPeer264]

Can you already confirm if that worked out on your tenant as well?

[pawelgrzybek]

I'm so sorry @JPeer264 allow me one more day and I'll come back to you. So sorry for the dalay, just wanted you to know how much I apreciate your help on this one.

[JPeer264]

Absolutely no hurries from my side.

No worries, I'm here to help 🤗

[pawelgrzybek]

Hey @JPeer264 so I spent some time on this one, and I think there is still some issue, and I believe the issue is on the sentry integration plugin side of things. Let me summarise what I found, what works great and what doesn't.

---

When all is set up locally, this all working great. To summarise (simplified version):

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project and the sentry headers are carried over to the Astro action which calls external API.
3. The external API receives a request and all sentry headers with it. Along the way the same trace id headers are carries a that procuces a nice trace view with spans from multiple services combiner into one.

Here is a secreenshot that presents traced created by sentry in the browser, the same one carried over to the action and the same one used on the api.

And the example how spans from multiple services are nicely connected into the same trace. Pretty much how you got it.

---

Unfortunately it doesn't behave in the same way on production. Here is how it works on production.

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project but headers are not carried over to the Astro action scope. So the API call sent from the action does not contain headers to chain the tracing spans.
3. The external API receives a request but it is also missing the sentry heaeders as they have never been sent from the Astro action.

Here is the equivalent screenshot with the trace id produced on the browser, then lost on the action and missing on the API. Instead of screenshots from the locally running services, these are logs from the cloudflare workers.

---

Potentially there is still some issue with my tracingTarget configuration. But I think there may also be some issue on the sentry astro integration plugin, because on non-localhost env headers are not passed along to the action.

Please let me know if I can provide any extra information to help Sentry team diagnose this. I will really appreciate if we could work on that together.

[JPeer264]

Thanks for taking a closer look on this. I also just took a look. It seems that Astro is running on Cloudflare Workers in this case instead of Cloudflare Pages (the old way of Cloudflare Pages) - which means that this is a new territory, which we didn't cover yet.

It is amazing that you are already running on Cloudflare Workers and that you've discovered that, but I'm afraid that your backend code is not instrumented at all - in other words, you can't do something right now.

The good news: I played around already with the SDK and got a working draft locally. I try to push this further next week and try to make it production ready. I'll create a ticket for it and link it here as a reference.

[pawelgrzybek]

This all makes perfect sense now. This is what I call good collaboration @JPeer264, you helped me identify incorrect configuration on my project, and I helped you to identify a missing feature. Love it ❣️

Since Astro and Cloudflare married recently, I would expect more and more folks are going to use combo of Astro + Workers instead of Astro + CF Pages. Also, using workers is an official recommendation by CF team for all Astro projects now. I think it makes sense for Sentry team to add this integration at this point.

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project (nn1.dev is a low risk project, this is just a meetup page and no-one is gonna die if something goes wrong).

For now, have a fab weekend 👋

[JPeer264]

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project

I highly appreciate your help on this one. It is also a huge help that your project is open source (kudos for that), which helped initially with finding the issue. I hope I can get something out tomorrow or the day after, I can tell you more then 🥳

[JPeer264]

👋

I'm writing / creating the PR because you opened the ticket 173143 (reference: getsentry/sentry#106855 (comment)). I was looking at your issue and saw that Sentry.getTraceData() was set manually. This is actually not needed and removed it - now it works.

So the problem now is that it should have worked fine with the additional data, but it seems that we might have a bug there if this is set twice (because we already instrument the fetch API and add the headers, so you don't have to).

This is how it looks like for me locally (the error is intended, as I haven't set up resend):

I will create a bug ticket on our side and reference this PR, so there is a backlink.

[pawelgrzybek]

Wow, soo all this was that simple? WOW, let me merge this one and confirm that here in a moment.

[JPeer264]

Can you already confirm if that worked out on your tenant as well?

[pawelgrzybek]

I'm so sorry @JPeer264 allow me one more day and I'll come back to you. So sorry for the dalay, just wanted you to know how much I apreciate your help on this one.

[JPeer264]

Absolutely no hurries from my side.

No worries, I'm here to help 🤗

[pawelgrzybek]

Hey @JPeer264 so I spent some time on this one, and I think there is still some issue, and I believe the issue is on the sentry integration plugin side of things. Let me summarise what I found, what works great and what doesn't.

---

When all is set up locally, this all working great. To summarise (simplified version):

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project and the sentry headers are carried over to the Astro action which calls external API.
3. The external API receives a request and all sentry headers with it. Along the way the same trace id headers are carries a that procuces a nice trace view with spans from multiple services combiner into one.

Here is a secreenshot that presents traced created by sentry in the browser, the same one carried over to the action and the same one used on the api.

And the example how spans from multiple services are nicely connected into the same trace. Pretty much how you got it.

---

Unfortunately it doesn't behave in the same way on production. Here is how it works on production.

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project but headers are not carried over to the Astro action scope. So the API call sent from the action does not contain headers to chain the tracing spans.
3. The external API receives a request but it is also missing the sentry heaeders as they have never been sent from the Astro action.

Here is the equivalent screenshot with the trace id produced on the browser, then lost on the action and missing on the API. Instead of screenshots from the locally running services, these are logs from the cloudflare workers.

---

Potentially there is still some issue with my tracingTarget configuration. But I think there may also be some issue on the sentry astro integration plugin, because on non-localhost env headers are not passed along to the action.

Please let me know if I can provide any extra information to help Sentry team diagnose this. I will really appreciate if we could work on that together.

[JPeer264]

Thanks for taking a closer look on this. I also just took a look. It seems that Astro is running on Cloudflare Workers in this case instead of Cloudflare Pages (the old way of Cloudflare Pages) - which means that this is a new territory, which we didn't cover yet.

It is amazing that you are already running on Cloudflare Workers and that you've discovered that, but I'm afraid that your backend code is not instrumented at all - in other words, you can't do something right now.

The good news: I played around already with the SDK and got a working draft locally. I try to push this further next week and try to make it production ready. I'll create a ticket for it and link it here as a reference.

[pawelgrzybek]

This all makes perfect sense now. This is what I call good collaboration @JPeer264, you helped me identify incorrect configuration on my project, and I helped you to identify a missing feature. Love it ❣️

Since Astro and Cloudflare married recently, I would expect more and more folks are going to use combo of Astro + Workers instead of Astro + CF Pages. Also, using workers is an official recommendation by CF team for all Astro projects now. I think it makes sense for Sentry team to add this integration at this point.

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project (nn1.dev is a low risk project, this is just a meetup page and no-one is gonna die if something goes wrong).

For now, have a fab weekend 👋

[JPeer264]

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project

I highly appreciate your help on this one. It is also a huge help that your project is open source (kudos for that), which helped initially with finding the issue. I hope I can get something out tomorrow or the day after, I can tell you more then 🥳

[JPeer264]

👋

I'm writing / creating the PR because you opened the ticket 173143 (reference: getsentry/sentry#106855 (comment)). I was looking at your issue and saw that Sentry.getTraceData() was set manually. This is actually not needed and removed it - now it works.

So the problem now is that it should have worked fine with the additional data, but it seems that we might have a bug there if this is set twice (because we already instrument the fetch API and add the headers, so you don't have to).

This is how it looks like for me locally (the error is intended, as I haven't set up resend):

I will create a bug ticket on our side and reference this PR, so there is a backlink.

[pawelgrzybek]

Wow, soo all this was that simple? WOW, let me merge this one and confirm that here in a moment.

[JPeer264]

Can you already confirm if that worked out on your tenant as well?

[pawelgrzybek]

I'm so sorry @JPeer264 allow me one more day and I'll come back to you. So sorry for the dalay, just wanted you to know how much I apreciate your help on this one.

[JPeer264]

Absolutely no hurries from my side.

No worries, I'm here to help 🤗

[pawelgrzybek]

Hey @JPeer264 so I spent some time on this one, and I think there is still some issue, and I believe the issue is on the sentry integration plugin side of things. Let me summarise what I found, what works great and what doesn't.

---

When all is set up locally, this all working great. To summarise (simplified version):

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project and the sentry headers are carried over to the Astro action which calls external API.
3. The external API receives a request and all sentry headers with it. Along the way the same trace id headers are carries a that procuces a nice trace view with spans from multiple services combiner into one.

Here is a secreenshot that presents traced created by sentry in the browser, the same one carried over to the action and the same one used on the api.

And the example how spans from multiple services are nicely connected into the same trace. Pretty much how you got it.

---

Unfortunately it doesn't behave in the same way on production. Here is how it works on production.

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project but headers are not carried over to the Astro action scope. So the API call sent from the action does not contain headers to chain the tracing spans.
3. The external API receives a request but it is also missing the sentry heaeders as they have never been sent from the Astro action.

Here is the equivalent screenshot with the trace id produced on the browser, then lost on the action and missing on the API. Instead of screenshots from the locally running services, these are logs from the cloudflare workers.

---

Potentially there is still some issue with my tracingTarget configuration. But I think there may also be some issue on the sentry astro integration plugin, because on non-localhost env headers are not passed along to the action.

Please let me know if I can provide any extra information to help Sentry team diagnose this. I will really appreciate if we could work on that together.

[JPeer264]

Thanks for taking a closer look on this. I also just took a look. It seems that Astro is running on Cloudflare Workers in this case instead of Cloudflare Pages (the old way of Cloudflare Pages) - which means that this is a new territory, which we didn't cover yet.

It is amazing that you are already running on Cloudflare Workers and that you've discovered that, but I'm afraid that your backend code is not instrumented at all - in other words, you can't do something right now.

The good news: I played around already with the SDK and got a working draft locally. I try to push this further next week and try to make it production ready. I'll create a ticket for it and link it here as a reference.

[pawelgrzybek]

This all makes perfect sense now. This is what I call good collaboration @JPeer264, you helped me identify incorrect configuration on my project, and I helped you to identify a missing feature. Love it ❣️

Since Astro and Cloudflare married recently, I would expect more and more folks are going to use combo of Astro + Workers instead of Astro + CF Pages. Also, using workers is an official recommendation by CF team for all Astro projects now. I think it makes sense for Sentry team to add this integration at this point.

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project (nn1.dev is a low risk project, this is just a meetup page and no-one is gonna die if something goes wrong).

For now, have a fab weekend 👋

[JPeer264]

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project

I highly appreciate your help on this one. It is also a huge help that your project is open source (kudos for that), which helped initially with finding the issue. I hope I can get something out tomorrow or the day after, I can tell you more then 🥳

[JPeer264]

👋

I'm writing / creating the PR because you opened the ticket 173143 (reference: getsentry/sentry#106855 (comment)). I was looking at your issue and saw that Sentry.getTraceData() was set manually. This is actually not needed and removed it - now it works.

So the problem now is that it should have worked fine with the additional data, but it seems that we might have a bug there if this is set twice (because we already instrument the fetch API and add the headers, so you don't have to).

This is how it looks like for me locally (the error is intended, as I haven't set up resend):

I will create a bug ticket on our side and reference this PR, so there is a backlink.

[pawelgrzybek]

Wow, soo all this was that simple? WOW, let me merge this one and confirm that here in a moment.

[JPeer264]

Can you already confirm if that worked out on your tenant as well?

[pawelgrzybek]

I'm so sorry @JPeer264 allow me one more day and I'll come back to you. So sorry for the dalay, just wanted you to know how much I apreciate your help on this one.

[JPeer264]

Absolutely no hurries from my side.

No worries, I'm here to help 🤗

[pawelgrzybek]

Hey @JPeer264 so I spent some time on this one, and I think there is still some issue, and I believe the issue is on the sentry integration plugin side of things. Let me summarise what I found, what works great and what doesn't.

---

When all is set up locally, this all working great. To summarise (simplified version):

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project and the sentry headers are carried over to the Astro action which calls external API.
3. The external API receives a request and all sentry headers with it. Along the way the same trace id headers are carries a that procuces a nice trace view with spans from multiple services combiner into one.

Here is a secreenshot that presents traced created by sentry in the browser, the same one carried over to the action and the same one used on the api.

And the example how spans from multiple services are nicely connected into the same trace. Pretty much how you got it.

---

Unfortunately it doesn't behave in the same way on production. Here is how it works on production.

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project but headers are not carried over to the Astro action scope. So the API call sent from the action does not contain headers to chain the tracing spans.
3. The external API receives a request but it is also missing the sentry heaeders as they have never been sent from the Astro action.

Here is the equivalent screenshot with the trace id produced on the browser, then lost on the action and missing on the API. Instead of screenshots from the locally running services, these are logs from the cloudflare workers.

---

Potentially there is still some issue with my tracingTarget configuration. But I think there may also be some issue on the sentry astro integration plugin, because on non-localhost env headers are not passed along to the action.

Please let me know if I can provide any extra information to help Sentry team diagnose this. I will really appreciate if we could work on that together.

[JPeer264]

Thanks for taking a closer look on this. I also just took a look. It seems that Astro is running on Cloudflare Workers in this case instead of Cloudflare Pages (the old way of Cloudflare Pages) - which means that this is a new territory, which we didn't cover yet.

It is amazing that you are already running on Cloudflare Workers and that you've discovered that, but I'm afraid that your backend code is not instrumented at all - in other words, you can't do something right now.

The good news: I played around already with the SDK and got a working draft locally. I try to push this further next week and try to make it production ready. I'll create a ticket for it and link it here as a reference.

[pawelgrzybek]

This all makes perfect sense now. This is what I call good collaboration @JPeer264, you helped me identify incorrect configuration on my project, and I helped you to identify a missing feature. Love it ❣️

Since Astro and Cloudflare married recently, I would expect more and more folks are going to use combo of Astro + Workers instead of Astro + CF Pages. Also, using workers is an official recommendation by CF team for all Astro projects now. I think it makes sense for Sentry team to add this integration at this point.

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project (nn1.dev is a low risk project, this is just a meetup page and no-one is gonna die if something goes wrong).

For now, have a fab weekend 👋

[JPeer264]

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project

I highly appreciate your help on this one. It is also a huge help that your project is open source (kudos for that), which helped initially with finding the issue. I hope I can get something out tomorrow or the day after, I can tell you more then 🥳

[JPeer264]

👋

I'm writing / creating the PR because you opened the ticket 173143 (reference: getsentry/sentry#106855 (comment)). I was looking at your issue and saw that Sentry.getTraceData() was set manually. This is actually not needed and removed it - now it works.

So the problem now is that it should have worked fine with the additional data, but it seems that we might have a bug there if this is set twice (because we already instrument the fetch API and add the headers, so you don't have to).

This is how it looks like for me locally (the error is intended, as I haven't set up resend):

I will create a bug ticket on our side and reference this PR, so there is a backlink.

[pawelgrzybek]

Wow, soo all this was that simple? WOW, let me merge this one and confirm that here in a moment.

[JPeer264]

Can you already confirm if that worked out on your tenant as well?

[pawelgrzybek]

I'm so sorry @JPeer264 allow me one more day and I'll come back to you. So sorry for the dalay, just wanted you to know how much I apreciate your help on this one.

[JPeer264]

Absolutely no hurries from my side.

No worries, I'm here to help 🤗

[pawelgrzybek]

Hey @JPeer264 so I spent some time on this one, and I think there is still some issue, and I believe the issue is on the sentry integration plugin side of things. Let me summarise what I found, what works great and what doesn't.

---

When all is set up locally, this all working great. To summarise (simplified version):

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project and the sentry headers are carried over to the Astro action which calls external API.
3. The external API receives a request and all sentry headers with it. Along the way the same trace id headers are carries a that procuces a nice trace view with spans from multiple services combiner into one.

Here is a secreenshot that presents traced created by sentry in the browser, the same one carried over to the action and the same one used on the api.

And the example how spans from multiple services are nicely connected into the same trace. Pretty much how you got it.

---

Unfortunately it doesn't behave in the same way on production. Here is how it works on production.

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project but headers are not carried over to the Astro action scope. So the API call sent from the action does not contain headers to chain the tracing spans.
3. The external API receives a request but it is also missing the sentry heaeders as they have never been sent from the Astro action.

Here is the equivalent screenshot with the trace id produced on the browser, then lost on the action and missing on the API. Instead of screenshots from the locally running services, these are logs from the cloudflare workers.

---

Potentially there is still some issue with my tracingTarget configuration. But I think there may also be some issue on the sentry astro integration plugin, because on non-localhost env headers are not passed along to the action.

Please let me know if I can provide any extra information to help Sentry team diagnose this. I will really appreciate if we could work on that together.

[JPeer264]

Thanks for taking a closer look on this. I also just took a look. It seems that Astro is running on Cloudflare Workers in this case instead of Cloudflare Pages (the old way of Cloudflare Pages) - which means that this is a new territory, which we didn't cover yet.

It is amazing that you are already running on Cloudflare Workers and that you've discovered that, but I'm afraid that your backend code is not instrumented at all - in other words, you can't do something right now.

The good news: I played around already with the SDK and got a working draft locally. I try to push this further next week and try to make it production ready. I'll create a ticket for it and link it here as a reference.

[pawelgrzybek]

This all makes perfect sense now. This is what I call good collaboration @JPeer264, you helped me identify incorrect configuration on my project, and I helped you to identify a missing feature. Love it ❣️

Since Astro and Cloudflare married recently, I would expect more and more folks are going to use combo of Astro + Workers instead of Astro + CF Pages. Also, using workers is an official recommendation by CF team for all Astro projects now. I think it makes sense for Sentry team to add this integration at this point.

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project (nn1.dev is a low risk project, this is just a meetup page and no-one is gonna die if something goes wrong).

For now, have a fab weekend 👋

[JPeer264]

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project

I highly appreciate your help on this one. It is also a huge help that your project is open source (kudos for that), which helped initially with finding the issue. I hope I can get something out tomorrow or the day after, I can tell you more then 🥳

[JPeer264]

👋

I'm writing / creating the PR because you opened the ticket 173143 (reference: getsentry/sentry#106855 (comment)). I was looking at your issue and saw that Sentry.getTraceData() was set manually. This is actually not needed and removed it - now it works.

So the problem now is that it should have worked fine with the additional data, but it seems that we might have a bug there if this is set twice (because we already instrument the fetch API and add the headers, so you don't have to).

This is how it looks like for me locally (the error is intended, as I haven't set up resend):

I will create a bug ticket on our side and reference this PR, so there is a backlink.

[pawelgrzybek]

Wow, soo all this was that simple? WOW, let me merge this one and confirm that here in a moment.

[JPeer264]

Can you already confirm if that worked out on your tenant as well?

[pawelgrzybek]

I'm so sorry @JPeer264 allow me one more day and I'll come back to you. So sorry for the dalay, just wanted you to know how much I apreciate your help on this one.

[JPeer264]

Absolutely no hurries from my side.

No worries, I'm here to help 🤗

[pawelgrzybek]

Hey @JPeer264 so I spent some time on this one, and I think there is still some issue, and I believe the issue is on the sentry integration plugin side of things. Let me summarise what I found, what works great and what doesn't.

---

When all is set up locally, this all working great. To summarise (simplified version):

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project and the sentry headers are carried over to the Astro action which calls external API.
3. The external API receives a request and all sentry headers with it. Along the way the same trace id headers are carries a that procuces a nice trace view with spans from multiple services combiner into one.

Here is a secreenshot that presents traced created by sentry in the browser, the same one carried over to the action and the same one used on the api.

And the example how spans from multiple services are nicely connected into the same trace. Pretty much how you got it.

---

Unfortunately it doesn't behave in the same way on production. Here is how it works on production.

1. I open the website and sentry creates a new trace for me.
2. I submit the form on Astro project but headers are not carried over to the Astro action scope. So the API call sent from the action does not contain headers to chain the tracing spans.
3. The external API receives a request but it is also missing the sentry heaeders as they have never been sent from the Astro action.

Here is the equivalent screenshot with the trace id produced on the browser, then lost on the action and missing on the API. Instead of screenshots from the locally running services, these are logs from the cloudflare workers.

---

Potentially there is still some issue with my tracingTarget configuration. But I think there may also be some issue on the sentry astro integration plugin, because on non-localhost env headers are not passed along to the action.

Please let me know if I can provide any extra information to help Sentry team diagnose this. I will really appreciate if we could work on that together.

[JPeer264]

Thanks for taking a closer look on this. I also just took a look. It seems that Astro is running on Cloudflare Workers in this case instead of Cloudflare Pages (the old way of Cloudflare Pages) - which means that this is a new territory, which we didn't cover yet.

It is amazing that you are already running on Cloudflare Workers and that you've discovered that, but I'm afraid that your backend code is not instrumented at all - in other words, you can't do something right now.

The good news: I played around already with the SDK and got a working draft locally. I try to push this further next week and try to make it production ready. I'll create a ticket for it and link it here as a reference.

[pawelgrzybek]

This all makes perfect sense now. This is what I call good collaboration @JPeer264, you helped me identify incorrect configuration on my project, and I helped you to identify a missing feature. Love it ❣️

Since Astro and Cloudflare married recently, I would expect more and more folks are going to use combo of Astro + Workers instead of Astro + CF Pages. Also, using workers is an official recommendation by CF team for all Astro projects now. I think it makes sense for Sentry team to add this integration at this point.

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project (nn1.dev is a low risk project, this is just a meetup page and no-one is gonna die if something goes wrong).

For now, have a fab weekend 👋

[JPeer264]

Please let me know if there is anything else I can help you with. I'll be very happy to assist and test some early releases on my production project

I highly appreciate your help on this one. It is also a huge help that your project is open source (kudos for that), which helped initially with finding the issue. I hope I can get something out tomorrow or the day after, I can tell you more then 🥳