Descrição do problema
O SquadsOnboardingFlow ignora a pausa. Um onboarding Squads pausado continua avançando normalmente e chega a completed, dando APTO pra alguém que pausou a jornada.
O WelcomeOnboardingFlow recusa nessa mesma situação. É inconsistência entre duas implementações do mesmo contrato: o OnboardingFlow::advance() documenta @throws OnboardingPausedException when the onboarding is paused, e só o Welcome cumpre.
Comportamento esperado
Avançar um onboarding pausado é recusado com OnboardingPausedException, em qualquer flow. Pra continuar, passa pelo ResumeOnboarding.
Comportamento atual
O SquadsOnboardingFlow::advance() não checa OnboardingStatus::Paused. Vai direto marcar o step como done e, se for o último, fecha o onboarding em completed, o que abre o gate APTO.
Não é só teoria de teste unitário: acontece pelo caminho público, via AdvanceStep, que também não checa status.
Passos para reproduzir
- Usuário com o
Welcome concluído e GitHub vinculado
StartOnboarding com OnboardingType::SquadsAdvanceStep no formPauseOnboarding, o status vira pausedAdvanceStep de novo
O step git_challenge é concluído, o onboarding vai pra completed e isCompleted($user, Squads) passa a devolver true.
Evidências
Mesmo cenário nos dois flows, pelo AdvanceStep:
| Flow |
Onboarding pausado + AdvanceStep |
WelcomeOnboardingFlow |
OnboardingPausedException, como o contrato manda |
SquadsOnboardingFlow |
conclui e dá APTO |
Ambiente
- Branch:
feat/squads
- Ambiente: camada de domínio, ainda sem UI plugada
Sugestão de correção (opcional)
Replicar no SquadsOnboardingFlow::advance() a checagem que o Welcome já faz:
if ($onboarding->status === OnboardingStatus::Paused) {
throw OnboardingPausedException::cannotAdvance($onboarding);
}Se a checagem tem que valer pra todo flow, talvez o lugar dela seja o AdvanceStep, e aí cada flow para de repetir. Fica a discussão de onde a regra mora, mas do jeito que está hoje um flow cumpre o contrato e o outro não.
Contexto adicional
Encontrado enquanto eu levantava o escopo real da #352. Menos urgente que a outra ponta, porque depende da pessoa pausar e alguém avançar mesmo assim, mas é barato de fechar.
Related to #341
Descrição do problema
O
SquadsOnboardingFlowignora a pausa. Um onboarding Squads pausado continua avançando normalmente e chega acompleted, dando APTO pra alguém que pausou a jornada.O
WelcomeOnboardingFlowrecusa nessa mesma situação. É inconsistência entre duas implementações do mesmo contrato: oOnboardingFlow::advance()documenta@throws OnboardingPausedException when the onboarding is paused, e só o Welcome cumpre.Comportamento esperado
Avançar um onboarding pausado é recusado com
OnboardingPausedException, em qualquer flow. Pra continuar, passa peloResumeOnboarding.Comportamento atual
O
SquadsOnboardingFlow::advance()não checaOnboardingStatus::Paused. Vai direto marcar o step comodonee, se for o último, fecha o onboarding emcompleted, o que abre o gate APTO.Não é só teoria de teste unitário: acontece pelo caminho público, via
AdvanceStep, que também não checa status.Passos para reproduzir
Welcomeconcluído e GitHub vinculadoStartOnboardingcomOnboardingType::SquadsAdvanceStepnoformPauseOnboarding, o status virapausedAdvanceStepde novoO step
git_challengeé concluído, o onboarding vai pracompletedeisCompleted($user, Squads)passa a devolver true.Evidências
Mesmo cenário nos dois flows, pelo
AdvanceStep:AdvanceStepWelcomeOnboardingFlowOnboardingPausedException, como o contrato mandaSquadsOnboardingFlowAmbiente
feat/squadsSugestão de correção (opcional)
Replicar no
SquadsOnboardingFlow::advance()a checagem que o Welcome já faz:Se a checagem tem que valer pra todo flow, talvez o lugar dela seja o
AdvanceStep, e aí cada flow para de repetir. Fica a discussão de onde a regra mora, mas do jeito que está hoje um flow cumpre o contrato e o outro não.Contexto adicional
Encontrado enquanto eu levantava o escopo real da #352. Menos urgente que a outra ponta, porque depende da pessoa pausar e alguém avançar mesmo assim, mas é barato de fechar.
Related to #341