Rotorsoft commented 8 months ago

Description

Create a new projection for contest-related events, aimed at capturing all pertinent details at the contest level. This projection will facilitate the presentation of contest information across various UI views, encompassing started contests, new threads and votes within contests, as well as winners. The implementation should include a query endpoint with filters to efficiently retrieve contest records from this projection.

Stakeholders

Product	Engineering
@zakhap	@Rotorsoft

Details

Develop a new projection specifically tailored for contest-related events - integrations
- ContestStarted (in contest manager)
- ThreadCreated (in platform - associated to contest)
- ThreadUpvoted (in platform - associated to contest)
- ContentAdded (to contest manager)
- VoteAdded (to contest manager)
- WinnerRecorded (in contest manager)
Projection schema + query interface
- Ensure the projection captures comprehensive contest-level details
- Enable seamless presentation of contest information across multiple UI views
- Include support for displaying started contests, new threads, votes within contests, and winners.
- Implement a query endpoint equipped with filters to retrieve contest records efficiently.

Integration Patterns Consideration:

In the context of integration patterns, the following approaches are being considered:

Platform Event Relay via RabbitMQ:
- Events emitted by the platform are relayed to RabbitMQ and processed by asynchronous integration policies. For instance, when content is created or upvoted within the platform, a new integration policy named ContestWorkerPolicy will be implemented. This policy's role will be to incorporate the new content and votes into the on-chain contest manager.
On-Chain Event Integration:
- On-chain events are routinely extracted from chain nodes into the platform by chain event workers. We must include all relevant events emitted by the contest manager into the new projection.

By adopting these integration patterns, we aim to establish seamless communication channels between the platform and external systems, facilitating a more efficient and robust data exchange and synchronization.

Acceptance Criteria

The new projection accurately captures all relevant contest-level details.
Contest information is effectively presented across various UI views.
The query endpoint allows for efficient retrieval of contest records with appropriate filters.
The feature is thoroughly tested and integrated into the existing system.
Documentation is provided for the implemented projection and query endpoint.

Model

Contest Lifecycle

Engineering Requirements

:bangbang: Projection tickets are divided into a projection side (for updating data) and a query side (for querying data)

Projection

[x] Path - /libs/model/src/contest/Contests.projection.ts
[x] Events - Schemas defined by event producers /libs/core/src/schemas/events.schemas.ts
- [x] ⛓ Network -> namespaces with contest managers
- [x] 🟧 RecurringContestManagerDeployed namespace, contest address, interval
- [x] 🟧 OneOffContestManagerDeployed namespace, contest address, length
- [x] ⛓ Contest Manager -> active contests, adding and reacting on content, recording winner and ending
- [x] 🟧 ContestStarted contest address, new instance id when recurring, start and end times
- [x] 🟧 ContestContentAdded contest address and id when recurring, content id and url, creator address
- [x] 🟧 ContestContentUpvoted contest address and id when recurring, content id, voter address and voting power
- [x] 🟧 ContestWinnersRecorded contest address and id when recurrig, winners as ranked array of creator addresses => ends contest!
[x] Schema - /libs/core/src/schemas/projections/contests.schemas.ts

erDiagram
    Community ||--|{ ContestManager: has
    ContestManager ||--|{ Contest : has
    Contest ||--|{ ContestAction : has

    Community {
       string id PK
       string namespace
       blob the_other_stuff "other community attributes"
    }

    ContestManager {
       int community_id FK
       string contest_address PK "on-chain contest manager address"
       int interval "recurrent contest interval, 0 when one-off" 
       datetime created_at
    }

    Contest {
      string contest_address FK "on-chain contest manager address"
      int contest_id PK "on-chain recurrent contest id, 0 when one-off"
      datetime start_time 
      datetime end_time
      string[] winners "nullable, ranked contest-winning creator addresses"
    }

    ContestAction {
      string contest_address PK,FK "on-chain contest manager address"
      int contest_id PK,FK "on-chain recurrent contest id, 0 when one-off"
      int content_id PK "on-chain content id"
      string actor_address PK "actor address"
      enum action PK "added, upvoted, etc - action in PK will allow same address to add, vote, etc"
      string content_url "this is the url of participating threads (or any other content)"
      number voting_power "voting power of address when action was recorded"
      datetime created_at
    }

[x] Repository/ORM
- /libs/model/src/models/contest_manager.ts
- constraints: positive intervals
- indexes: PK, FK
- /libs/model/src/models/contest.ts
- constraints: none
- indexes: PK, FK, startTime/endTime
- /libs/model/src/models/contest_action.ts
- constraints: winners nullable
- indexes: PK, FK
[x] Rules
- transformations: simple on-chain event mappings
- augmentation: none
- aggregation: none
- idempotent: compare last projected event date

Queries

:bangbang: Queries should not raise non-auth related errors, instead return empty or filtered result sets... there might be exceptions to this rule

🟩 GetAllContests

[x] Path - /libs/model/src/contest/GetAllContests.query.ts
[ ] Authorization
- who's authorized to query - roles, groups? @zakhap
[ ] Schema (in/out) - /libs/core/src/schemas/queries/contests.schemas.ts
- filters, rules
- validation
- pagination
- response
[x] Routing - GET /api/v1/contests.getAll

Unit Testing

[x] Path - /libs/model/test/contests-projection-lifecycle.spec.ts
Happy Path
- Given: a stream of events gets projected on two contests (recurring and one-off)
- When: a winner recorded event gets projected
- Then: a query of the winner contest should reflect all events, and both contests should be projected
Sad Path
- When: a contest deployed event with a non-existing namespace
- Then: should raise invalid state exception - the system should not get to this state

Rotorsoft commented 7 months ago

@kurtisassad let's start refining the engineering requirements and provide a rough estimate

CowMuon commented 6 months ago

Looks like Kurtis estimated at a 3. Tossing back to @Rotorsoft since Kurtis is out next week (and then when he is back, Ryan is out until 4/16.)

Needless to say, we would prefer not to have to wait for Kurtis to be back for this work to be done.

CowMuon commented 6 months ago

Roger will reach out to Protocol team today to confirm model/schema is correct.

rbennettcw commented 6 months ago

Looks like this can work. As discussed in the worker policy PR, maybe we can add chainNodeUrl to the ContentAdded/ContentUpvoted events so that we don't need to query across Thread->Community->ChainNode in the worker policy.

Should be fine unless for some reason the policy will fire months/years after the event was emitted at a time when the RPC url is no longer valid– edge case.

Rotorsoft commented 6 months ago

Looks like this can work. As discussed in the worker policy PR, maybe we can add chainNodeUrl to the ContentAdded/ContentUpvoted events so that we don't need to query across Thread->Community->ChainNode in the worker policy.

Should be fine unless for some reason the policy will fire months/years after the event was emitted at a time when the RPC url is no longer valid– edge case.

I think we can solve this in the projection/query... we can include chain node attributes in the general (getAll) query, or create a getById query with more details

hicommonwealth / commonwealth

🟩 Contests Projection #6820