Fix $ in path parameters treated as Regex.Replace back-references

[Copilot]

Regex.Replace interprets $0, $1, $& etc. as back-references in the replacement string. Path parameter values containing a literal $ (e.g. "$0something") were silently corrupted instead of being passed through.

Changes

• v2 + v3 operation compilers: escape $ → $$ in the replacement string before passing to Regex.Replace
• Test server: add EchoPathController that returns its string path parameter verbatim
• Regression test: v3 test asserting "$0something" round-trips through a path parameter unchanged
• master merged: brings in RuntimeHelpers unit tests, CI concurrency group, and Option form-data fix ([Repo Assist] Fix Option types sending Some(value) in form data bodies #298)

// Before — $0 consumed as back-reference, value silently mangled
Regex.Replace(url, pattern, value)

// After — literal dollar sign preserved
Regex.Replace(url, pattern, value.Replace("$", "$$"))

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR updates runtime helper behavior and adds unit tests around runtime serialization/utilities, alongside a CI workflow concurrency tweak.

Changes:

• Add a new RuntimeHelpersTests.fs test suite and include it in the test project.
• Update RuntimeHelpers.toQueryParams to return an empty list for null inputs and adjust related runtime helper behavior.
• Add an option-unwrapping step in getPropertyValues to avoid emitting Some(value) in form data, plus workflow concurrency configuration.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
tests/SwaggerProvider.Tests/SwaggerProvider.Tests.fsproj	Includes the new RuntimeHelpers unit test file in compilation.
tests/SwaggerProvider.Tests/RuntimeHelpersTests.fs	Adds broad unit coverage for RuntimeHelpers (query params, content creation, headers, etc.).
src/SwaggerProvider.Runtime/RuntimeHelpers.fs	Alters query param serialization flow and introduces F# option unwrapping in getPropertyValues.
.github/workflows/dotnetcore.yml	Adds workflow-level concurrency/cancel-in-progress behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

getPropertyValues now unwraps F# options before building form/urlencoded content, but there are no assertions covering this behavior in the new RuntimeHelpers unit tests. Please add a regression test that verifies Some(value) becomes the inner value and None/null is omitted when producing key/value sequences.

[Copilot]

There’s no coverage for Option<Guid>[] query parameters (including arrays containing None/null). Given the runtime has special-cases for other Option<_>[] types, adding a regression test here would help prevent serialization bugs/crashes specific to GUID option arrays.

[Copilot]

PR description/title focus on escaping $ in path parameters, but the actual diff in this PR is limited to RuntimeHelpers changes/tests and CI concurrency. If the $ path fix is already present from another merge, consider updating the PR description to reflect what’s actually changing here (or include the missing diffs) to avoid review/traceability confusion.

[Copilot]

array<Option<Guid>> is currently routed to toStrArray, which will serialize values as Some(...) and will throw a NullReferenceException when the array contains None (compiled as null). It should be handled the same way as the other option arrays (e.g. via toStrArrayOpt / Array.choose id) so None items are skipped and Some g becomes g.ToString().

Suggested change

	| :? array<Option<Guid>> as xs -> xs |> toStrArray name
	| :? array<Option<Guid>> as xs -> xs |> toStrArrayOpt name

[Copilot]

Query param serialization for float32/double uses ToString() (via toStrArray), which is culture-sensitive. On machines with a comma decimal separator this will produce values like "1,5" in URLs; consider formatting numeric types with InvariantCulture (and aligning/adding tests accordingly) to make query strings stable across locales.