Development: Refactor exercise participation endpoints to use DTOs

[dogusaytok]

Summary

This PR migrates nine exercise participation endpoints from entity-backed response bodies to dedicated DTOs. It introduces lazy-safe, data-minimal participation response records, adapts the Angular client back to the existing component-facing models, and updates server, client, architecture, and Playwright contract tests. The Exercise entity-return architecture budget is reduced from 23 to 14 violations.

Checklist

General

• I tested all changes and their related features with all corresponding user types on a test server.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Server

• Important: I implemented the changes with a very good performance and prevented too many (unnecessary) and too complex database calls.
• I strictly followed the principle of data economy for all database calls.
• I strictly followed the server coding and design guidelines and the REST API guidelines.
• I added multiple integration tests (Spring) related to the features (with a high test coverage).
• I documented the Java code using JavaDoc style.

Client

• Important: I implemented the changes with a very good performance, prevented too many (unnecessary) REST calls and made sure the UI is responsive, even with large data (e.g. using paging).
• I strictly followed the principle of data economy for all client-server REST calls.
• I strictly followed the client coding guidelines.
• I added multiple integration tests (Vitest) related to the features (with a high test coverage), while following the test guidelines.
• I documented the TypeScript code using JSDoc style.

Changes affecting Programming Exercises

• High priority: I tested all changes and their related features with all corresponding user types on a test server configured with the integrated lifecycle setup (LocalVC and LocalCI).
• I tested all changes and their related features with all corresponding user types on a test server configured with LocalVC and Jenkins.

Motivation and Context

Exercise participation REST endpoints currently expose JPA entities directly. This leaks persistence details into the API, transfers incidental data, risks recursive response graphs and lazy-loading failures, and contributes to the Exercise module's architecture-test debt.

This migration establishes an explicit, data-minimal participation API contract while preserving the existing behavior and component-facing client models.

Description

• Introduce StudentParticipationDTO and dedicated DTOs for lean submissions, results, teams, exercises, and courses.
• Map only initialized Hibernate associations to avoid implicit database queries and LazyInitializationExceptions.
• Preserve participation and exercise discriminators, programming repository information, build-plan state, dates, participant information, and the submission/result data required by polling.
• Migrate the following participation responses:
  • starting an exercise;
  • starting practice mode;
  • resuming a programming exercise;
  • requesting feedback;
  • retrieving a participation for the current user;
  • retrieving a participation with its latest result;
  • updating a presentation score;
  • updating individual due dates;
  • cleaning up a programming build plan.
• Add explicit request validation and nullability to the existing participation update DTO boundaries.
• Add an Angular DTO adapter that restores the existing participation, submission, and result models, converts dates, and reconnects client-side back-references.
• Update participation and course-exercise services to use DTOs at the HTTP boundary.
• Update Spring integration tests, Vitest tests, and Playwright polling types for the new contracts.
• Reduce the Exercise entity-return architecture budget from 23 to 14.

Steps for Testing

Prerequisites:

• 1 Instructor
• 1 Tutor
• 2 Students
• 1 Course with Text, Modeling, and Programming Exercises
• 1 Team Exercise with both students assigned to a team
• Presentation scores enabled
• Athena enabled for testing feedback requests
• A Programming Exercise configured first with LocalVC/LocalCI and then with LocalVC/Jenkins

1. Log in as a student and start each individual exercise type.
2. Verify that each exercise opens normally and the participation contains the correct exercise and participant information.
3. Start the team exercise and verify that the team and its students are displayed correctly.
4. Submit to the programming exercise and verify that result polling completes and the latest build result is displayed.
5. Request feedback for a supported exercise and verify that the updated participation and result state are displayed.
6. Move an exercise past its due date, start practice mode, and verify that the practice participation opens normally.
7. Resume an inactive programming participation and verify that its repository, branch, and build-plan state remain available.
8. Log in as a tutor, update a participation's presentation score, and verify that the change is displayed.
9. Log in as an instructor, update individual participation due dates, and verify that the changed dates are displayed.
10. Clean up a programming participation's build plan and verify that the participation state is updated without UI errors.
11. Inspect the participation REST responses and verify that they contain DTO-shaped data without recursive submission.participation.submissions or result.submission graphs.

Exam Mode Testing

Prerequisites:

• 1 Instructor
• 2 Students
• 1 Test Exam with a Programming Exercise

1. Log in as an instructor and prepare the test exam.
2. Participate in the exam as a student.
3. Open the programming exercise, submit a solution, and wait for the build result.
4. Verify that participation and result polling work and that the programming exercise UI remains unchanged.
5. Repeat the test with a second test-exam participation and verify that both participations remain distinguishable.

Testserver States

You can manage test servers using Helios. Check environment statuses in the environment list. To deploy to a test server, go to the CI/CD page, find your PR or branch, and trigger the deployment.

Review Progress

Performance Review

• I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance even for very large courses with more than 2000 students.
• I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance even for very large courses with more than 2000 students.

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Exam Mode Test

• Test 1
• Test 2

Test Coverage

Client

Class/File	Line Coverage	Lines	Expects	Ratio
course-exercise.service.ts	95.83%	111	21	18.9
participation.service.ts	81.88%	308	43	14.0
student-participation.dto.ts	74.64%	184	?	?

Server

Class/File	Line Coverage	Lines
ParticipationCourseContextDTO.java	100.00%	10
ParticipationDueDateUpdateDTO.java	100.00%	15
ParticipationExerciseContextDTO.java	83.33%	58
ParticipationSubmissionDTO.java	100.00%	22
ParticipationSubmissionResultDTO.java	100.00%	14
ParticipationTeamDTO.java	100.00%	17
ParticipationUpdateDTO.java	100.00%	9
StudentParticipationDTO.java	97.06%	77
ParticipationDeletionResource.java	96.43%	90
ParticipationResource.java	87.68%	299
ParticipationRetrievalResource.java	78.95%	146
ParticipationUpdateResource.java	89.71%	155

Last updated: 2026-07-04 12:19:26 UTC

[github-actions]

End-to-End Test Results

Phase	Status	Details
All Tests	❌ Failed	Tests Passed ☑️ Skipped ⚠️ Failed ❌️ Time ⏱ All E2E Tests Report (PR) 313 ran 308 passed 4 skipped 1 failed 53m 27s

❌ Failed Tests

• Exam participation › Early hand-in with continue and reload page › Participates in the exam, hand-in early, but instead continues (5m 12s)

Flakiness Scores for Failed Tests

Test	Flakiness Score	Default Branch Failure Rate	Combined Failure Rate
e2e/exam/ExamParticipation.spec.ts#Exam participation › Early hand-in with continue and reload page › Participates in the exam, hand-in early, but instead continues	0%	0.8%	0.3%

Test Strategy: Running all tests (configuration or infrastructure changes detected)

Overall: ❌ E2E tests failed

🔗 Workflow Run · 📊 Test Report