Ing 467

[mariohd]

[> Stacked on #ING-466 — base this PR on ing-466, not main. It builds on the shared connection services introduced there, and amends two of them.

Context

ING-467. The GraphQL counterpart of per-object connection routing for wallets (dive-in T19-GQL). ING-466 added the REST write path plus the shared validation and persistence services; the UI drives wallets through GraphQL, so it needs the same routing exposed there.

Description

A new ConnectionsInput carries one optional choice per category — payment, tax, accounting, crm — each either a connection code or a behavior:

input ConnectionsInput {
  payment: ConnectionChoiceInput
  tax: ConnectionChoiceInput
  accounting: ConnectionChoiceInput
  crm: ConnectionChoiceInput
}

input ConnectionChoiceInput {
  code: String
  behavior: ConnectionBehaviorEnum   # inherit | skip
}

specific is deliberately absent from the enum — it's implied by supplying a code. The argument is added to Wallets::Create/UpdateInput and both recurring-rule inputs, and schema.graphql / schema.json are regenerated (both are spec-enforced). The existing paymentMethod input is untouched, and everything stays behind the multi_connection flag.

No new service logic. The mutations already forward their arguments to the same write path as REST, so validation, the flag gate and persistence came for free.

Reviewer note — why this touches two ING-466 files

GraphQL passes nested inputs as GraphQL::Schema::InputObject, not Hash, and the validator guards with is_a?(Hash) — so every GraphQL request would have been rejected as invalid_connections. Both shared services now normalise at their boundary, converting only when the value isn't already a Hash: HashWithIndifferentAccess#to_hash returns string keys, which silently broke choice[:code] on the recurring-rule path. ING-462 and the future invoice surfaces share these services, so the fix benefits them too.

Testing

9 new mutation examples — 4 on create, 5 on update, the latter covering inherit clearing a row, the per-rule path through RecurringTransactionRules::UpdateService, an unresolvable code, and the flag gate. Regression: 691 examples across the shared services, the wallet REST suites, both mutations and the schema-dump spec. All green, Rubocop clean.

[lago-claude-ai-agent]

Automated pre-review (advisory, not a required check) — verdict: HOLD · CI green

HOLD — recurring-rule creation can silently accept an unresolvable connection.

• In Wallets::RecurringTransactionRules::CreateService, AttachToResourceService.call! raises with its own failed result, but the BaseService::FailedResult rescue discards that result and returns the still-successful recurring-rule result. Propagate the failure as the update sibling does, and add a create-path regression asserting an unknown nested connection code fails without persisting the wallet, rule, or overrides.