Summary
gateway destination update silently discards --url (and --cli-path) when --type is omitted — which is the normal way to run an update, since the type is already stored.
Reproduce
hookdeck gateway destination update des_xxx --url https://new.example.com/hook
Exits 0. The URL is not applied. Adding --type HTTP makes it work.
Root cause
buildDestinationConfigFromIndividualFlags switches on destType. With --type omitted, destType is "" and the switch falls to default:, which tolerates an empty type and therefore never reaches the case "HTTP" branch that assigns config["url"]. Same for case "CLI" and --cli-path.
Why it matters
Same silent-success shape as the delivery-policy and --config bugs fixed in #392: the command reports success while doing nothing. update is precisely the command where omitting --type is natural.
Note on a related fix
#392 added type resolution for the delivery-policy guard (fetching the stored type when --type is omitted). That resolved type is deliberately not fed into config building, because doing so would make --url start working only when a rate-limit flag happened to also be present — an inconsistency worse than the current uniform failure. Fixing this properly means resolving the type for config building generally, not reusing that path opportunistically.
Suggested testing
Acceptance: destination update --url without --type, then read back and assert the URL changed. This is exactly the class the new delivery-group acceptance tests cover for rate limits, and it would have caught this.
Related
Filed by Claude on Phil's behalf, from release-candidate testing.
Summary
gateway destination updatesilently discards--url(and--cli-path) when--typeis omitted — which is the normal way to run an update, since the type is already stored.Reproduce
Exits 0. The URL is not applied. Adding
--type HTTPmakes it work.Root cause
buildDestinationConfigFromIndividualFlagsswitches ondestType. With--typeomitted,destTypeis""and the switch falls todefault:, which tolerates an empty type and therefore never reaches thecase "HTTP"branch that assignsconfig["url"]. Same forcase "CLI"and--cli-path.Why it matters
Same silent-success shape as the delivery-policy and
--configbugs fixed in #392: the command reports success while doing nothing.updateis precisely the command where omitting--typeis natural.Note on a related fix
#392 added type resolution for the delivery-policy guard (fetching the stored type when
--typeis omitted). That resolved type is deliberately not fed into config building, because doing so would make--urlstart working only when a rate-limit flag happened to also be present — an inconsistency worse than the current uniform failure. Fixing this properly means resolving the type for config building generally, not reusing that path opportunistically.Suggested testing
Acceptance:
destination update --urlwithout--type, then read back and assert the URL changed. This is exactly the class the new delivery-group acceptance tests cover for rate limits, and it would have caught this.Related
--configinstances of this shapeFiled by Claude on Phil's behalf, from release-candidate testing.