Peer Mentor Profile Aggregation Service

Medium complexity with dependencies on four repositories plus the certification status service. All five dependencies must be integration-ready before end-to-end testing of this service is possible. The parallel fetch design using Future.wait reduces perceived latency but requires careful testing of timeout and partial failure scenarios. Allocate dedicated QA time for organization-specific filtering logic — HLF and Blindeforbundet rules must each be verified with representative test data.

Because this service decouples the BLoC from individual repositories, changes to any single repository interface are isolated here, reducing regression surface across the feature. No backend deployment required.

Orchestrates Future.wait over four parallel repository calls (profile, certification, activity log, assignments) with per-source fallback via fetchWithFallback(). The merge() method accepts the four resolved models and delegates status derivation to CertificationStatusService before constructing the final PeerMentorDetailModel. Organization-specific filtering is applied post-merge: HLF certification fields are included only when orgId matches HLF tenants; assignment history is scoped to Blindeforbundet org context. Errors from individual futures are caught inside fetchWithFallback, returning the provided fallback value so merge() always receives a complete argument list.

This pattern keeps the BLoC's error handling limited to whole-model failures rather than per-field nullability.