Feat: Complete Problem Module Implementation

[MathCunha16]

Summary

This Pull Request completes the end-to-end implementation of the Problem domain module for the Go backend.

It includes:

• Complete ProblemUseCase implementation
• Optimized list queries using a lightweight ProblemSummary read model
• REST HTTP Handler improvements
• Route mapping updates
• Comprehensive Unit and Integration Test coverage
• OpenAPI 3.0 documentation

---

✨ Key Changes

⚙️ 1. Domain & Persistence (internal/domain/, internal/adapter/out/persistence/)

ProblemSummary Read Model

Introduced a lightweight ProblemSummary model for list operations.

Benefits:

• Avoids loading heavy fields such as:
  • error_description
  • solution
• Reduces database I/O.
• Reduces response payload size.
• Improves list endpoint performance.

Query Optimization

Updated FindAllByProjectID to select only the required columns:

SELECT
    id,
    project_id,
    title,
    status,
    severity,
    created_at,
    updated_at

instead of using:

SELECT *

---

⚙️ 2. Use Case Layer (internal/usecase/)

problem_usecase.go

Updated GetAllByProjectID to return:

model.Page[port.ProblemSummary]

instead of loading the full entity.

Unit Tests (problem_usecase_test.go)

Added 16 unit tests covering:

• Create
• GetByID
• GetAllByProjectID
• Update
• UpdateStatus
• Delete

Coverage includes:

• Successful operations
• Project not found
• Problem not found
• Edge cases using testify mocks

---

🌐 3. Web Layer (internal/adapter/in/web/)

problem_handler.go

Implemented several handler improvements:

• Added the missing return when handling ErrProjectNotFound in GetAll, preventing duplicate 404 and 500 responses.
• Fixed Update, UpdateStatus, and Delete to correctly return 404 Not Found when usecase.ErrProblemNotFound occurs instead of falling through to 500 Internal Server Error.
• Corrected the logging tag in UpdateStatus ([ProblemHandler.UpdateStatus]).

router.go

Registered the dedicated status update endpoint:

PATCH /api/v1/projects/:project_id/problems/:problem_id/status

---

🧪 4. Integration Testing

Updated test_helper_test.go to wire:

• Problem repository
• Problem use case
• Problem handler

into the shared SetupTestApp.

HTTP Integration Tests (problem_handler_test.go)

Added 31 integration tests using Gin and an in-memory SQLite database (:memory:).

Coverage includes:

• Successful creation with Location header validation
• Retrieval by ID
• Paginated ProblemSummary listing
• Project isolation
• Partial updates (PATCH)
• Status transitions (PATCH /status)
• Permanent deletion with persistence verification
• Invalid UUIDs
• Missing required fields
• Title validation
• Page size validation (size > 100)
• Unauthorized requests (401)

---

📚 5. OpenAPI 3.0 Documentation

Updated docs/openapi.yaml with:

Schemas

• Problem
• ProblemSummary
• ProblemStatus
• ProblemSeverity
• CreateProblemCommand
• UpdateProblemCommand
• UpdateProblemStatusCommand
• ProblemSummaryPage

Endpoints

Documented all Problem endpoints:

• POST
• GET (List)
• GET (By ID)
• PATCH (Update)
• PATCH (Status Update)
• DELETE

---

🧪 Test Execution

Run the full test suite:

cd backend-go
go test ./... -v

Run only the Problem use case tests:

go test ./internal/usecase/... -v -run TestProblem

Run only the Problem handler integration tests:

go test ./internal/adapter/in/web/handler/... -v -run TestProblemHandler

Summary by CodeRabbit

• Novos recursos

  • Adicionado gerenciamento completo de problemas vinculados a projetos.
  • É possível criar, consultar, listar com paginação, atualizar, alterar status e excluir problemas.
  • Incluídas validações de autenticação, identificadores, campos obrigatórios e isolamento por projeto.
  • Adicionados status, severidade, resumos e respostas padronizadas para erros e sucessos.

• Documentação

  • Atualizada a especificação da API com modelos, endpoints, paginação, validações e códigos de resposta.

• Testes

  • Incluídos testes unitários e de integração para os principais fluxos e cenários de erro.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: 7117f43d-4286-441c-8e42-42bc0488d460

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• ✅ Review completed - (🔄 Check again to review again)

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (3)

backend-go/internal/adapter/in/web/handler/problem_handler.go (1)

37-45: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Registre o erro antes de responder 500 em Create.

Os outros métodos deste handler chamam log.Printf antes de retornar 500. Create não registra o erro. Isso remove a informação de diagnóstico do único caminho de falha inesperada da criação.

♻️ Correção proposta

 		if errors.Is(err, usecase.ErrProjectNotFound) {
 			c.JSON(http.StatusNotFound, gin.H{"error": err.Error()})
 			return
 		}
+		log.Printf("[ProblemHandler.Create] %v", err)
 		c.JSON(http.StatusInternalServerError, gin.H{"error": "Internal server error"})
 		return

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend-go/internal/adapter/in/web/handler/problem_handler.go` around lines
37 - 45, In the Create method’s unexpected-error branch, log the returned err
with log.Printf before sending the HTTP 500 response, matching the logging
behavior of the handler’s other methods. Keep the existing not-found response
and internal-server-error response unchanged.

backend-go/internal/adapter/in/web/handler/problem_handler_test.go (2)

214-223: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Use require nas asserções de tipo da resposta paginada.

assert.Equal não interrompe o subteste. Se o status não for 200, page["content"] fica nil e a asserção de tipo em content := page["content"].([]interface{}) provoca panic. Isso oculta a causa real da falha. O mesmo padrão aparece nas linhas 241 e nos blocos de setup que usam createdProblem["id"].(string).

♻️ Correção proposta

-		resp := app.DoRequest(t, http.MethodGet, urlPath, nil, true)
-		assert.Equal(t, http.StatusOK, resp.StatusCode)
+		resp := app.DoRequest(t, http.MethodGet, urlPath, nil, true)
+		require.Equal(t, http.StatusOK, resp.StatusCode)
 
 		var page map[string]interface{}
 		err := json.NewDecoder(resp.Body).Decode(&page)
 		require.NoError(t, err)
 
-		content := page["content"].([]interface{})
+		content, ok := page["content"].([]interface{})
+		require.True(t, ok, "campo content ausente ou com tipo inesperado")
 		assert.Len(t, content, 10) // default page size is 10

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend-go/internal/adapter/in/web/handler/problem_handler_test.go` around
lines 214 - 223, Substitua por require as asserções que validam tipos e valores
essenciais na resposta paginada, especialmente antes de acessar page["content"]
em problem handler tests. Aplique o mesmo padrão ao bloco próximo da linha 241 e
aos setups que fazem createdProblem["id"].(string), garantindo que a execução
seja interrompida antes de qualquer type assertion que possa causar panic.

---

144-166: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Adicione um teste de isolamento entre projetos com dois projetos existentes.

Os casos de falha usam apenas o UUID zero, que corresponde a um projeto inexistente. Isso não verifica o cenário em que os dois projetos existem e o problema pertence ao outro projeto. TestProblemHandler_GetAll já cria o Projeto A e o Projeto B para esse fim. Aplique o mesmo padrão a Get, Update, UpdateStatus e Delete, e espere 404 quando o problema pertencer a outro projeto.

💚 Caso de teste sugerido

t.Run("Get failure - problem belongs to another project", func(t *testing.T) {
	respOther := app.DoRequest(t, http.MethodPost, "/api/v1/projects", []byte(`{"name":"Other Project"}`), true)
	var otherProject map[string]interface{}
	require.NoError(t, json.NewDecoder(respOther.Body).Decode(&otherProject))
	otherProjectID := otherProject["id"].(string)

	urlGet := fmt.Sprintf("/api/v1/projects/%s/problems/%s", otherProjectID, problemID)
	resp := app.DoRequest(t, http.MethodGet, urlGet, nil, true)
	assert.Equal(t, http.StatusNotFound, resp.StatusCode)
})

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend-go/internal/adapter/in/web/handler/problem_handler_test.go` around
lines 144 - 166, Adicione testes de isolamento entre projetos nos fluxos de Get,
Update, UpdateStatus e Delete em TestProblemHandler, criando dois projetos reais
e associando o problema a um deles. Para cada operação, use o ID do outro
projeto na URL e valide HTTP 404, mantendo os testes existentes para UUIDs
inexistentes e formatos inválidos.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@backend-go/internal/adapter/out/persistence/problem_repository.go`:
- Around line 53-54: Atualize a consulta definida em selectQuery para ordenar
primeiro por created_at DESC e, em seguida, por id como critério secundário
determinístico, preservando o filtro por project_id e a paginação existente.

In `@backend-go/internal/usecase/problem_usecase.go`:
- Around line 101-123: Evite perda de atualizações concorrentes nos fluxos de
edição de problema: em backend-go/internal/usecase/problem_usecase.go, linhas
101-123, substitua o Save após a leitura por uma atualização condicional usando
versão ou updated_at; em linhas 130-141, aplique o mesmo controle à alteração de
status. Preserve as validações existentes e faça a operação falhar quando o
registro tiver sido alterado desde a leitura.

---

Nitpick comments:
In `@backend-go/internal/adapter/in/web/handler/problem_handler_test.go`:
- Around line 214-223: Substitua por require as asserções que validam tipos e
valores essenciais na resposta paginada, especialmente antes de acessar
page["content"] em problem handler tests. Aplique o mesmo padrão ao bloco
próximo da linha 241 e aos setups que fazem createdProblem["id"].(string),
garantindo que a execução seja interrompida antes de qualquer type assertion que
possa causar panic.
- Around line 144-166: Adicione testes de isolamento entre projetos nos fluxos
de Get, Update, UpdateStatus e Delete em TestProblemHandler, criando dois
projetos reais e associando o problema a um deles. Para cada operação, use o ID
do outro projeto na URL e valide HTTP 404, mantendo os testes existentes para
UUIDs inexistentes e formatos inválidos.

In `@backend-go/internal/adapter/in/web/handler/problem_handler.go`:
- Around line 37-45: In the Create method’s unexpected-error branch, log the
returned err with log.Printf before sending the HTTP 500 response, matching the
logging behavior of the handler’s other methods. Keep the existing not-found
response and internal-server-error response unchanged.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: 2d900464-64a1-4de0-b9f8-952cff63d0b0

📥 Commits

Reviewing files that changed from the base of the PR and between 6ca615e and 9ce6413.

📒 Files selected for processing (10)

• backend-go/cmd/api/main.go
• backend-go/docs/openapi.yaml
• backend-go/internal/adapter/in/web/handler/problem_handler.go
• backend-go/internal/adapter/in/web/handler/problem_handler_test.go
• backend-go/internal/adapter/in/web/handler/test_helper_test.go
• backend-go/internal/adapter/in/web/router.go
• backend-go/internal/adapter/out/persistence/problem_repository.go
• backend-go/internal/domain/port/problem_repository.go
• backend-go/internal/usecase/problem_usecase.go
• backend-go/internal/usecase/problem_usecase_test.go