[NickJosevski]

Problem

resolveSpaceId is the single choke point every space-scoped call goes through (client.ts doCommand/request/del, packageRepository, observabilityRepository, kubernetesMonitorRepository). It queries /spaces?partialName=<value> and then requires an exact Name match:

if (spaces.TotalResults === 0) throw new Error(`No spaces exist with name `);
spaces.Items.forEach((space) => { if (space.Name == spaceName) spaceId = space.Id; });

So passing a space id fails. Spaces-1795 returns zero results from a partialName filter and throws No spaces exist with name 'Spaces-1795'.

That is surprising for two reasons:

• OctopusDeploy/push-package-action documents its space input as "The name or ID of a space", which is currently untrue for the ID half.
• A caller in this very repo already assumes it works — createReleaseCommandV1.test.ts passes spaceName: "Spaces-1".

The practical cost: every consumer has to hardcode a space name, so renaming a space silently breaks every pipeline referencing it. We just had to raise PRs across 5 repos for exactly this.

Change

Try the name match first, then fall back to an id lookup, and only when the value is shaped like a space id (/^Spaces-\d+$/).

This mirrors the CLI, which deliberately prefers name and falls back to id — see OctopusDeploy/cli#30 and client_factory.go's SpaceNameOrID.

Properties worth calling out:

• Existing behaviour is unchanged. A name that resolves today resolves identically, via the same single request.
• No extra request on the happy path. The id lookup only runs when the name match fails and the value looks like an id.
• Name wins over id. A space literally named Spaces-9999 still resolves by name, so this cannot silently retarget an existing caller. Covered by a test.
• Public signature is unchanged; the parameter is renamed spaceName → spaceNameOrId for clarity.

Verification

• src/spaceResolver.test.ts added — 6 tests covering exact name, non-exact partial name, id fallback, name-preferred-over-id, no id lookup for non-id-shaped input, and unmatched id. All pass.
• tsc --noEmit clean.
• eslint clean on spaceResolver.ts. The test file reports the same consistent-type-assertions error that versionCheck.test.ts and createReleaseCommandV1.test.ts already report for the identical as unknown as Client stub pattern — I followed the existing convention rather than diverge from it.
• Full suite: 6 suites / 15 tests fail both before and after this change (they need a live Octopus server in this environment). This change takes passing suites 8 → 9 and passing tests 51 → 57.

Follow-up

Once this ships, push-package-action and create-release-action can take a space id, and create-release-action's action.yml description can be corrected to match push-package-action's.

🤖 Generated with Claude Code