Subscriptions #10114
Subscriptions #10114
Conversation
Signed-off-by: Alexey Zinoviev <alexey.zinoviev@xored.com>
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a subscription management system for the Huly Platform, adding support for tracking workspace subscriptions with billing provider integration. The implementation provides a provider-agnostic abstraction for managing subscription statuses, types, and billing periods.
Key changes:
- Added comprehensive subscription type definitions and enums for status and types
- Implemented service operations for upserting subscriptions (billing service only)
- Added user operations for retrieving subscriptions with role-based access control
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| server/account/src/types.ts | Defines subscription enums (SubscriptionStatus, SubscriptionType) and Subscription interface with provider-agnostic fields |
| server/account/src/serviceOperations.ts | Implements upsertSubscription function for billing service to create/update subscriptions |
| server/account/src/operations.ts | Adds getSubscriptions function with role-based access control for workspace owners/maintainers |
| server/account/src/collections/postgres/postgres.ts | Integrates subscription collection into PostgreSQL database implementation |
| server/account/src/collections/postgres/migrations.ts | Adds V19 migration to create subscription table with proper indexes and constraints |
| server/account/src/collections/mongo.ts | Integrates subscription collection into MongoDB database implementation |
| server/account/src/tests/serviceOperations.test.ts | Comprehensive test coverage for upsertSubscription function |
| server/account/src/tests/operations.test.ts | Complete test coverage for getSubscriptions function including access control |
|
Connected to Huly®: UBERF-13958 |
Signed-off-by: Alexey Zinoviev <alexey.zinoviev@xored.com>
| } | ||
| // TODO: verify all plans are present in the config - take them from model? | ||
| // hardcoded check for now | ||
| const mustHave = ['common@tier', 'rare@tier', 'epic@tier', 'legendary@tier'] |
There was a problem hiding this comment.
If we take this from model, should it be something like billing:tier:Common?
There was a problem hiding this comment.
yes, we can, although I think we should still have type and plan fields in the descriptor object explicitly even if we declare them this way
| export async function createServer (ctx: MeasureContext, config: Config): Promise<{ app: Express, close: () => void }> { | ||
| const app = express() | ||
| app.use(cors()) | ||
| app.use(express.json({ limit: '50mb' })) |
There was a problem hiding this comment.
nit: limit makes sense only for services that accept huge payload, can be removed here
There was a problem hiding this comment.
i thought it also helps to prevent dealing with unwanted oversized payloads which someone with bad intentions might be sending? If not I can remove, if it helps I'd reduce the limit to 5mb or something like this?
There was a problem hiding this comment.
As far as I remember there is a default limit that is small enough. 50mb is used to increase the limit.
Signed-off-by: Alexey Zinoviev <alexey.zinoviev@xored.com>
2 participants
Subs feature preview (complete backend & client)