Pass tracecontext from PDF generator cookies back to app

[martinothamar]

Description

When rendering PDF, get W3C traceparent propagated by the app and pass it back to the app when making subsequent requests.

Backend PR: Altinn/app-lib-dotnet#924

Tested locally using Application Insights both with OTel and the classic App Insights SDK

I don't know what the best place for this code is, but at least it needs to be pretty far upstream so that the interceptor is added before any downstream requests are made.

Related Issue(s)

• N/A

Verification/QA

• Manual functionality testing
  • I have tested these changes manually
  • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
  • No testing done/necessary
• Automated tests
  • Unit test(s) have been added/updated
  • Cypress E2E test(s) have been added/updated
  • No automatic tests are needed here (no functional changes/additions)
  • I want someone to help me make some tests
• UU/WCAG (follow these guidelines until we have our own)
  • I have tested with a screen reader/keyboard navigation/automated wcag validator
  • No testing done/necessary (no DOM/visual changes)
  • I want someone to help me perform accessibility testing
• User documentation @ altinn-studio-docs
  • Has been added/updated
  • No functionality has been changed/added, so no documentation is needed
  • I will do that later/have created an issue
• Support in Altinn Studio
  • Issue(s) created for support in Studio
  • This change/feature does not require any changes to Altinn Studio
• Sprint board
  • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
  • I don't have permissions to do that, please help me out
• Labels
  • I have added a kind/* label to this PR for proper release notes grouping
  • I don't have permissions to add labels, please help me out

[bjosttveit]

Looks good to me. Although since this appears to require no hooks, I suppose it does not need to lie in the render function of index? Not completely sure what the best place is either but i guess the closest thing we have to an established pattern for things like this would be something similar to src/features/baseurlinjection which is just imported directly in the index file

[martinothamar]

Extracted it into a separate function in a file in src/feature (but still use the same evt handler)

[bjosttveit]

Extracted it into a separate function in a file in src/feature (but still use the same evt handler)

That looks great, much cleaner

[martinothamar]

Are there any good ways to unit-test this stuff? For example a snapshot of how the resulting request headers look like depending on the query parameter and cookies would be nice, not sure if there are similar tests around

[olemartinorg]

@martinothamar

Are there any good ways to unit-test this stuff?

I would probably have made a Cypress test for this. Loading an existing instance with ?pdf=1, intercept all requests and assert they contain the header we want.

[bjosttveit]

Have you tried running cypress locally? 😅
npx cypress open -e environment=tt02
if you set it.only(...) on the test and click the pdf test in the cypress runner you can get a little faster feedback than testing in GitHub

[martinothamar]

Yeah the normal runner doesn't work for me, probably because I'm in WSL. Managed to run it in Docker but I'm not getting the same error so I think I can't run this locally atm

[sonarqubecloud]

Quality Gate failed

Failed conditions
2.6% Coverage on New Code (required ≥ 45%)
0.0% Condition Coverage on New Code (required ≥ 45%)

See analysis details on SonarQube Cloud