fix(multi-video-player): use more specific path split in fromPullUrl

[Jade Fauvelle (Skyzreal)]

Change fromPullUrl to split on '/jet/jrec/pull/' instead of '/pull/' to properly support reverse proxy deployments with path-based routing

[github-actions]

Let maintainers know that an action is required on their side

• Add the label release-required Please cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module) when you request a maintainer to cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module)

• Add the label release-blocker Follow-up is required before cutting a new release if a follow-up is required before cutting a new release

• Add the label publish-required Please publish libraries (`Devolutions.Gateway.Utils`, OpenAPI clients, etc) when you request a maintainer to publish libraries (Devolutions.Gateway.Utils, OpenAPI clients, etc.)

• Add the label publish-blocker Follow-up is required before publishing libraries if a follow-up is required before publishing libraries

[Benoît Cortier (CBenoit)]

question: Shouldn’t the base URL be everything that is before /jet? E.g.: gatewayUrl = https://gw1.somedomain.ninja:7000/

[Benoît Cortier (CBenoit)]

Upon re-reviewing this, I’m going to push back on changing the public API here.

The current shape of the API is deliberate: GatewayRecordingApi takes a Gateway base URL and knows internally that the relevant endpoints live under /jet/jrec, /jet/sessions, etc. In other words, callers give it "the thing closest to the real base" (e.g. https://gw1.somewhere.ninja/), and the class owns the knowledge of /jet/… paths.

Switching the constructor to take a jetApiUrl (e.g. https://gw1.somewhere.ninja/jet/) moves those details into the caller. That’s an abstraction leak.

On the /jet/jrec "duplication" point: I don’t really see a concrete problem there. Yes, we repeat /jet/jrec in several methods, but in this case I’d rather be explicit than DRY:

• Each method clearly shows the full path it is calling.
• There’s no confusion about which endpoints live where.
• The gain from refactoring this into a shorter base (jetApiUrl) is small, while the cost in terms of API semantics and abstraction is somewhat high (especially, both the old and new APIs still take a string, but the value must be carefully updated; this is a silent breaking change).

So I don’t think changing the public API just to avoid repeating /jet or /jet/jrec is worth it.

That said, it seems to me that fromPullUrl on master is buggy: fromPullUrl should derive the Gateway base URL (everything before /jet), and currently it seems to split at /pull instead of /jet. But maybe I’m misunderstanding the split method of JavaScript. Can you confirm that?

If you’re OK with that direction, I would be happy to review a follow-up that only adjusts fromPullUrl and leaves the constructor signature and responsibilities as they are.

[Jade Fauvelle (Skyzreal)]

Thanks for the feedback Benoit!
I’ve updated only fromPullUrl instead so it derives the correct base URL without needing to strip path segments after.
You're definitely right, and it avoids manipulating the base URL directly, this is more simple than my previous approach as well :)

[Benoît Cortier (CBenoit)]

LGTM! Thank you!

[Benoît Cortier (CBenoit)]

Please, update the PR title / body to reflect the changes, and feel free to merge yourself 👍