Implement Config Service connection test orchestration
epic-external-system-integration-configuration-core-services-task-013 — Add connection testing capability to the Integration Config Service that delegates to the appropriate adapter's testConnection() method. Handles credential decryption from vault, adapter invocation, result normalization, and persisting last-tested timestamp and status to the database. Used by the setup wizard to validate credentials before saving.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 5 - 253 tasks
Can start after Tier 4 completes
Handles integration between different epics or system components. Requires coordination across multiple development streams.
Implementation Notes
Implement the 10-second timeout using Future.timeout() on the adapter's testConnection() call: `await adapter.testConnection(creds).timeout(const Duration(seconds: 10), onTimeout: () => ConnectionTestResult.timeout())`. Credential decryption and DB persistence should be sequential (decrypt → test → persist), not parallel, to ensure credentials are only in scope during the test. The vault fetch and credential scoping should use a helper method that takes a callback to guarantee the decrypted object goes out of scope after the callback completes — this is the safest memory pattern in Dart. For the BLoC integration, the connection test should emit a sequence of states: ConnectionTestInProgress → ConnectionTestSuccess/ConnectionTestFailed.
Do not cache connection test results — each call must invoke the adapter fresh. The Supabase update for last_tested_at should use `.update({'last_tested_at': DateTime.now().toIso8601String(), 'last_test_status': result.statusString}).eq('org_id', orgId).eq('integration_type', integrationType.name)` to avoid a full record overwrite.
Testing Requirements
Unit tests with mocked adapter registry, vault, and Supabase client: (1) successful test returns normalized ConnectionTestResult with success=true and latencyMs populated, (2) adapter timeout after 10s returns success=false with errorCode='TIMEOUT', (3) adapter throws exception returns success=false with errorCode='ADAPTER_ERROR', (4) adapter not found returns AdapterNotFoundError, (5) credentials not in vault returns CredentialsNotFoundError, (6) last_tested_at and last_test_status are persisted for both success and failure outcomes, (7) decrypted credential is NOT present in the returned ConnectionTestResult. Use Dart's Future.delayed in mock adapters to simulate timeout. Verify that timed-out calls do not leave dangling futures. Target 85%+ branch coverage.
Each of the five external systems (Xledger, Dynamics, Cornerstone, Consio, Bufdir) has a different authentication flow, field schema, and error format. Forcing them into a uniform adapter interface may require compromises that result in leaky abstractions or make the adapter contract too complex to maintain.
Mitigation & Contingency
Mitigation: Design the IntegrationAdapter interface with a loose invoke() payload rather than a typed one, allowing each adapter to declare its own input/output schema. Use integration type metadata in the registry to document per-adapter quirks. Build Xledger first as the most documented API, then adapt the interface based on learnings.
Contingency: If the uniform interface cannot accommodate all five systems, split into two interface tiers: a simple polling/export adapter and a richer bidirectional adapter, with the registry declaring which tier each system implements.
Development and testing of the Cornerstone and Consio adapters depends on NHF providing sandbox API access. If credentials or documentation are delayed, these adapters cannot be validated, blocking the epic's acceptance criteria.
Mitigation & Contingency
Mitigation: Implement Xledger and Dynamics adapters first (better-documented, sandbox available). Create a mock adapter for Cornerstone/Consio using recorded API responses for CI testing. Proactively request sandbox access from NHF at project kickoff.
Contingency: Ship the epic with Cornerstone/Consio adapters in a 'stub' state (connectivity test returns a simulated success, invoke() is not production-wired) and gate the NHF integration behind a feature flag until real API access is obtained.
Real-world field mappings may include nested transformations, conditional logic, and data type coercions (e.g., Norwegian date formats, currency rounding rules) that the Field Mapping Resolver's initial design does not accommodate, requiring scope expansion mid-epic.
Mitigation & Contingency
Mitigation: Gather actual field mapping examples from Blindeforbundet (Xledger) and HLF (Dynamics) before designing the resolver. Identify the most complex transformation required and ensure the resolver design handles it. Limit Phase 1 to direct field renaming and format conversion only.
Contingency: If complex transformations are required, implement a simple expression evaluator (e.g., JSONata or a custom mini-DSL) as an extension point in the resolver, delivering basic mappings first and complex ones in a follow-up task.