Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Mentorship: request lifecycle + capacity enforcement (Phase 6.3)

Aperta
  • Qualcosa non va?
#10 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
csharp, postgresql
Ambito
backend-api-design, databases, testing

Direzione di ricerca

Inizia risolvendo dependency #9 e leggendo i pattern esistenti per gli endpoint dei moduli e i test harness, in particolare IEndpointModule.MapEndpoints e Members/MembersTestHarness.cs. Traccia come vengono usati Result, ProblemDetails, il contesto EF Core di proprietà del modulo e IEmailSender. Il lavoro è completato quando gli xUnit tests coprono l'intero ciclo di vita, le regole di autorizzazione, la race condition sulla capacità, la paginazione, gli errori stabili e un comportamento dell'email sicuro in caso di errore.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

mentorship

Scope

Mentee-initiated requests through to active mentorships.

Lifecycle

Pending → Accepted ⇒ ActiveMentorship | Declined(reason) | Withdrawn — then Active → Concluded (either side).

Data model

public sealed class MentorshipRequest
{
    public Guid Id { get; set; }
    public Guid MentorId { get; set; }
    public Guid MenteeId { get; set; }
    public string Message { get; set; }
    public RequestStatus Status { get; set; }     // Pending | Accepted | Declined | Withdrawn
    public string? DeclineReason { get; set; }
}

public sealed class Mentorship
{
    public Guid Id { get; set; }
    public Guid MentorId { get; set; }
    public Guid MenteeId { get; set; }
    public MentorshipStatus Status { get; set; }  // Active | Concluded
}

Endpoints (active-member policy)

Method Path Notes
POST /mentorship/requests mentee → mentor; message + goals
GET /mentorship/requests/incoming / outgoing paginated
POST /mentorship/requests/{id}/accept mentor only; creates Mentorship
POST /mentorship/requests/{id}/decline mentor only; reason optional but stored
POST /mentorship/requests/{id}/withdraw mentee only
GET /mentorship/mine active + concluded mentorships for caller
POST /mentorship/{id}/conclude either participant

Rules

  • Capacity on accept: active mentorships < Capacity, else 409 mentorship.at_capacity. Hitting capacity auto-sets IsAcceptingMentees = false (manual re-enable when a mentorship concludes — do not auto-flip back).
  • No duplicate open request to the same mentor; no self-mentorship; mentor must be accepting.
  • Brevo (existing IEmailSender, best-effort): request received → mentor; accepted/declined → mentee.

Error codes

mentorship.not_found, mentorship.at_capacity, mentorship.not_accepting, mentorship.duplicate_request, mentorship.invalid_state, mentorship.forbidden

Dependencies

Blocked by #9.

Acceptance criteria

  • Full transition matrix tested incl. wrong-party actions (mentee accepting, etc.)
  • Capacity race: two concurrent accepts at capacity-1 → exactly one succeeds (constraint or transaction, tested)
  • Emails logged-not-thrown on failure
Conventions (project-wide, non-negotiable)
  • .NET 9, records for immutable shapes, file-scoped namespaces, primary constructors where they read well. Minimal-API endpoints grouped per module via IEndpointModule.MapEndpoints.
  • Result<T> (SharedKernel) instead of exception-driven control flow. Endpoint results map failures to ProblemDetails with the stable error codes listed above — the frontend keys off them.
  • Module owns its EF Core DbContext mapped to its own Postgres schema. Modules never reference each other's internals — cross-module needs go through a public contract interface or an in-process domain event (IEventPublisher).
  • All external calls (GitHub, Stripe, Brevo, Cloudinary, Meilisearch) behind interfaces owned by the consuming module.
  • Every list endpoint paginated (offset is fine). xUnit tests in tests/CommunityPro.Tests/<Module>/ following the existing harness patterns (see Members/MembersTestHarness.cs).
Lingua principale
C#
Stelle
0
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CommunityPro/community-pro-api

Tutte le issue di CommunityPro/community-pro-api

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.