fix: explicitly use URLSearchParams when constructing send to email magic links

[jessicamcinchak]

See #help-issues thread from Tewkesbury here: https://opendigitalplanning.slack.com/archives/C0241GWFG4B/p1736501911947289

Here's what's happening:

• ✔️ Our submissions log button downloads as expected
• ✔️ The magic link saved in our email_applications audit table downloads as expected
• ❌ The magic link when clicked directly from the body of a Gov Notify email does not download as expected and instead throws error: error: "Missing values required to access application files" (email forwarded to devops@)
  • It appears Gov Notify has automatically wrapped the link (eg https://linkprotect.cudasvc.com/url?a={our encoded URL} which fails to properly decode the second query param in the request
  • Eg see amp;localAuthority when inspecting the network request here:
    

Open questions:

• Is this bug even on our side of the fence, is this a recent Gov Notify change ?? Can't find anything specific in the docs about this third party service! https://www.notifications.service.gov.uk/using-notify/links-and-URLs
• Is this isolated to Tewkesbury or their internal network/email applications, why haven't we heard from high-volume send to email teams like Bucks about same?

Changes & testing:

• I'm hoping that explicitly calling new URLSearchParams() when constructing our magic link may fix this instead of the previous plain string template approach? Any other more robust ideas here?
• Use the pizza to send a Gov Notify email and check the URL in the email body
  • The magic link downloads as expected for me on the pizza, but is notably NOT wrapped in the linkprotect URL, which likely confirms this is unqiue to Tewkesbury and not Gov Notify as a whole
  • Likely not able to test this any further locally without deploying to prod & asking Tewkesbury to test next live app received or on staging?
• Unfortunately any solution here is only going to apply to new/future emails and not ones already received, so we'll want to continue pointing councils to the Submissions Logs for those if we hear of others with this issue

[github-actions]

Removed vultr server and associated DNS entries

[DafyddLlyr]

Suggested change

	const applicationFilesDownloadLink = `${process.env.API_URL_EXT}/download-application-files/${sessionId}?${params}`;
	const applicationFilesDownloadLink = `${process.env.API_URL_EXT}/download-application-files/${sessionId}?${params.toString()}`;

[DafyddLlyr]

Not tested yet (doing so now) but this flagged as an issue with this approach!

[DafyddLlyr]

Ah ignore this sorry - when templated this parses to a string natively without .toString() - neat!

[jessicamcinchak]

Exactly 🙂 there's a few inconsistent uses of this around the code base we should cleanup sometime though outside of this

[RODO94]

Working for me when testing.

nit: Only thing I would think about adding for robustness is something in the downloadApplicationFiles code to remove these ;amp additions. We can't manage how IT teams wrap ext network requests, and from my view it's likely this could happen again so could be good to start a function now to clean the query params?

[DafyddLlyr]

I think this is an issue with Tewksbury's IT wrapping and incorrectly decoding the URL.

The URL is correct and well formatted - nobody else has reported this and using web APIs (URLSearchParams) is a robust and reliable approach.

We could certainly make this a little bit more robust by -

• constructing a URL using new URL()
• validating this URL

However - I don't think this would actually resolve the issue here, just give us a better leg to stand on / more confidence on our side of the fence.

[DafyddLlyr]

BTW - just to be explicit - tested on pizza and working as expected ✅