Enhance document attachment with schema validation #1213
Conversation
|
Warning Rate limit exceeded@chacha912 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 18 minutes and 44 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (10)
WalkthroughThis update introduces comprehensive schema management capabilities to the project. It adds new API endpoints, protobuf messages, database methods, and client/server logic for creating, retrieving, listing, and deleting document schemas. Schema validation is enforced on document updates, and integration tests verify correct schema attachment, validation, and lifecycle operations. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant AdminAPI
participant Backend
participant Database
Client->>AdminAPI: CreateSchema(project, name, version, body, rules)
AdminAPI->>Backend: CreateSchema(projectID, name, version, body, rules)
Backend->>Database: CreateSchemaInfo(projectID, name, version, body, rules)
Database-->>Backend: SchemaInfo / error
Backend-->>AdminAPI: Schema / error
AdminAPI-->>Client: Schema / error
Client->>AdminAPI: GetSchemas(project, name)
AdminAPI->>Backend: GetSchemas(projectID, name)
Backend->>Database: GetSchemaInfos(projectID, name)
Database-->>Backend: []*SchemaInfo
Backend-->>AdminAPI: []*Schema
AdminAPI-->>Client: []*Schema
Client->>AdminAPI: RemoveSchema(project, name, version)
AdminAPI->>Backend: IsSchemaAttached(projectID, schemaKey)
Backend->>Database: IsSchemaAttached(projectID, schemaKey)
Database-->>Backend: bool
alt Not attached
AdminAPI->>Backend: RemoveSchema(projectID, name, version)
Backend->>Database: RemoveSchemaInfo(projectID, name, version)
Database-->>Backend: success/error
Backend-->>AdminAPI: success/error
else Attached
AdminAPI-->>Client: error (schema in use)
end
sequenceDiagram
participant Client
participant YorkieServer
participant Backend
participant Database
Client->>YorkieServer: AttachDocument(docID, schema)
YorkieServer->>Backend: GetSchema(projectID, name, version)
Backend->>Database: GetSchemaInfo(projectID, name, version)
Database-->>Backend: SchemaInfo
Backend-->>YorkieServer: Schema
YorkieServer->>Database: UpdateDocInfoSchema(refKey, schemaKey)
Database-->>YorkieServer: success
YorkieServer-->>Client: AttachDocumentResponse(schemaRules)
Suggested labels
Suggested reviewers
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
hackerwins
force-pushed
the
schema
branch
2 times, most recently
from
084b0c9 to
fa4e587
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1213 +/- ##
==========================================
- Coverage 37.80% 37.30% -0.51%
==========================================
Files 182 186 +4
Lines 28810 30147 +1337
==========================================
+ Hits 10893 11245 +352
- Misses 17031 18001 +970
- Partials 886 901 +15 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
hackerwins
force-pushed
the
schema
branch
3 times, most recently
from
ddab90b to
789a172
Compare
hackerwins
changed the title
hackerwins
added
protocol changed 📝
hackerwins
force-pushed
the
main
branch
6 times, most recently
from
ee9bbd2 to
a98ac24
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 29
🔭 Outside diff range comments (1)
api/yorkie/v1/resources.proto (1)
430-443: 🛠️ Refactor suggestionPrefer an enum for
Rule.typeinstead of free-form stringFree-text type names hinder validation and make forward-compatibility harder.
Define an enum (e.g.,RulePrimitiveType) and reference it here; clients can still fall back toUNSPECIFIEDfor unknown values.enum PrimitiveType { PRIMITIVE_TYPE_UNSPECIFIED = 0; PRIMITIVE_TYPE_STRING = 1; PRIMITIVE_TYPE_NUMBER = 2; ... } message Rule { string path = 1; PrimitiveType type = 2; }
🧹 Nitpick comments (18)
server/backend/database/doc_info.go (1)
43-45: Add JSON tag andomitemptyto keep BSON/JSON representations alignedThe new field will always be serialized into BSON (and possibly JSON) even when empty, which consumes space and may break older consumers that don’t expect the key. Consider:
- // Schema is the schema of the document. - Schema string `bson:"schema"` + // Schema is the key of the schema associated with this document. + // Use `omitempty` so blank values are not persisted/returned. + Schema string `bson:"schema,omitempty" json:"schema,omitempty"`client/options.go (1)
99-100: Default behaviour when no schema is suppliedStoring an empty string is fine, but an explicit pointer (
*string) would let the transport layer distinguish “not provided” vs “provided but empty”. Up to you, but worth considering before GA.client/client.go (1)
310-313: Consider validatingopts.Schemabefore sending
Schemais sent unchecked. Passing an empty string when the server expects a valid ID leads to a server-side validation error that could have been caught earlier.
At minimum, warn whenopts.Schema == ""; ideally, return a typed error.api/yorkie/v1/yorkie.proto (2)
58-62:schemafield lacks field-behavior / validation hintsThe meaning of an empty string versus an omitted value is ambiguous.
Adding an annotation such asgoogle.api.field_behavior = OPTIONAL(or documenting that an empty string is ignored) clarifies the contract and helps generated client stubs.
65-69: Use fully-qualified type to prevent future name collisions
repeated Rule schema_rules = 4;relies on an unqualified type name that is currently resolved via the import.
Being explicit (yorkie.v1.Rule) makes intent clear and avoids breakage if anotherRuleappears in this file later.-repeated Rule schema_rules = 4; +repeated yorkie.v1.Rule schema_rules = 4;api/types/schema.go (1)
30-47: Missing struct-level documentation & marshaling parity
Schemais exported but lacks a GoDoc comment – this hurts public API readability.
In addition, you expose JSON tags only; BSON tags will probably be needed for the Mongo layer just like inSchemaInfo, otherwise manual copying is required every time the struct crosses that boundary.server/backend/database/mongo/indexes.go (2)
55-56: Remember to updateCollectionsinitialisation migrationsAdding
ColSchemashere is fine, but the cluster initialisation / migration code (if any) must also be taught about the new collection so that deployments on existing clusters don’t miss it.
157-167: Consider a TTL or partial index on dropped schemasIf schemas can be superseded and never referenced again, a partial index (
removed_at: null) or TTL could keep index size small.api/docs/yorkie/v1/resources.openapi.yaml (1)
1512-1567: Document the new OpenAPI components
RuleandSchemalack descriptions, examples, and$refreuse in request/response bodies.
Adding even one-line summaries will make the generated docs much clearer for SDK consumers.server/backend/database/schema_info.go (1)
25-47: BSON/JSON tag asymmetry will cause manual copy churn
SchemaInfouses BSON tags only whiletypes.Schemauses JSON tags only.
Every conversion now requires an explicit copy (ToSchema,FromSchema, …).
Add symmetric tags (bothbsonandjson) to one of them to remove this boilerplate.server/rpc/yorkie_server.go (1)
179-217: Consider refactoring the attachment limit and schema update logic for clarity.The current conditional logic
if project.HasAttachmentLimit() || (docInfo.Schema == "" && req.Msg.Schema != "")combines two different concerns:
- Checking attachment limits
- Setting initial schema on first attachment
This makes the code harder to understand and maintain.
Consider separating these concerns:
-if project.HasAttachmentLimit() || (docInfo.Schema == "" && req.Msg.Schema != "") { +// Handle initial schema setup for new documents +if docInfo.Schema == "" && req.Msg.Schema != "" { + schemaName, schemaVersion, err = converter.FromSchemaKey(req.Msg.Schema) + if err != nil { + return nil, err + } + schema, err = schemas.GetSchema(ctx, s.backend, project.ID, schemaName, schemaVersion) + if err != nil { + return nil, err + } +} + +// Check attachment limits if configured +if project.HasAttachmentLimit() { locker := s.backend.Lockers.Locker(documents.DocAttachmentKey(docKey)) defer func() { if err := locker.Unlock(); err != nil { logging.DefaultLogger().Error(err) } }() count, err := documents.FindAttachedClientCount(ctx, s.backend, docKey) if err != nil { return nil, err } if err := project.CheckAttachmentLimit(count); err != nil { return nil, err } +} - if count == 0 { - schemaName, schemaVersion, err = converter.FromSchemaKey(req.Msg.Schema) - if err != nil { - return nil, err - } - schema, err = schemas.GetSchema(ctx, s.backend, project.ID, schemaName, schemaVersion) - if err != nil { - return nil, err - } - if err := documents.UpdateDocInfoSchema(ctx, s.backend, docInfo.RefKey(), req.Msg.Schema); err != nil { - return nil, err - } - } +// Update schema for first attachment +if docInfo.Schema == "" && req.Msg.Schema != "" { + locker := s.backend.Lockers.Locker(documents.DocAttachmentKey(docKey)) + defer func() { + if err := locker.Unlock(); err != nil { + logging.DefaultLogger().Error(err) + } + }() + + count, err := documents.FindAttachedClientCount(ctx, s.backend, docKey) + if err != nil { + return nil, err + } + + if count == 0 { + if err := documents.UpdateDocInfoSchema(ctx, s.backend, docInfo.RefKey(), req.Msg.Schema); err != nil { + return nil, err + } + } }server/rpc/admin_server.go (2)
41-42: Missing package grouping / accidental import growth
schemasis added at the very bottom of the import list. The existing file keeps Yorkie-local imports grouped together and sorted alphabetically. Please keep the style consistent to avoid noisy diffs in the future.
726-728: Error message is too genericReturning
fmt.Errorf("schema %s is being used", schema)discards context (project name/id). Consider wrapping withconnect.CodeFailedPreconditionand including the project or document count so callers can decide next steps.server/backend/database/mongo/client.go (2)
1019-1033: Documentupdated_attimestamp is not refreshedSchema changes are a meaningful document update. Consider touching
updated_attogether withschemaso that stale-doc scavengers don’t mis-classify it."$set": bson.M{ - "schema": schemaKey, + "schema": schemaKey, + "updated_at": gotime.Now(), },
1843-1859:IsSchemaAttachedquery needs an index onschemaHeavy
FindOnescans ondocuments.schemawithout an index will degrade with document growth.
Ensure(project_id, schema)compound index is created inindexes.go.server/schemas/schemas.go (1)
70-75: Silent success on empty schema name
GetSchemasreturns(nil, nil)whenname == "", making it indistinguishable from “not found”.
Prefer returningErrInvalidArgumentso API users know they mis-used the call.api/yorkie/v1/v1connect/admin.connect.go (2)
252-276: Matchingconnect.NewClientwiring verifiedEach new field is wired with the expected procedure constant and type parameters.
Minor nit: this generated block is getting long; consider suppressing generated code from reviews (e.g.,//nolint:dupl,lllor PR filters) to reduce noise.
519-593: Handler construction extendedHandlers for the new RPCs are registered exactly once each. Good catch on keeping alphabetical grouping.
One optional improvement: this generated switch-case is now ~50 paths; generation is fine, but consider using amap[string]http.Handlerin future generator versions for marginal routing performance gains.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
api/yorkie/v1/admin.pb.gois excluded by!**/*.pb.goapi/yorkie/v1/resources.pb.gois excluded by!**/*.pb.goapi/yorkie/v1/yorkie.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (34)
admin/client.go(1 hunks)api/converter/from_pb.go(3 hunks)api/converter/to_pb.go(1 hunks)api/docs/yorkie/v1/admin.openapi.yaml(17 hunks)api/docs/yorkie/v1/resources.openapi.yaml(1 hunks)api/docs/yorkie/v1/yorkie.openapi.yaml(3 hunks)api/types/create_schema_fields.go(1 hunks)api/types/project.go(1 hunks)api/types/project_test.go(1 hunks)api/types/schema.go(1 hunks)api/yorkie/v1/admin.proto(3 hunks)api/yorkie/v1/resources.proto(1 hunks)api/yorkie/v1/v1connect/admin.connect.go(18 hunks)api/yorkie/v1/yorkie.proto(1 hunks)client/client.go(2 hunks)client/options.go(2 hunks)pkg/document/document.go(6 hunks)pkg/schema/ruleset_validator.go(1 hunks)pkg/schema/ruleset_validator_test.go(1 hunks)server/backend/database/database.go(3 hunks)server/backend/database/doc_info.go(2 hunks)server/backend/database/memory/database.go(4 hunks)server/backend/database/memory/indexes.go(2 hunks)server/backend/database/mongo/client.go(3 hunks)server/backend/database/mongo/indexes.go(3 hunks)server/backend/database/schema_info.go(1 hunks)server/documents/documents.go(1 hunks)server/packs/serverpack.go(0 hunks)server/rpc/admin_server.go(2 hunks)server/rpc/connecthelper/status.go(2 hunks)server/rpc/yorkie_server.go(4 hunks)server/schemas/schemas.go(1 hunks)test/integration/admin_test.go(2 hunks)test/integration/schema_test.go(1 hunks)
💤 Files with no reviewable changes (1)
- server/packs/serverpack.go
🧰 Additional context used
🧬 Code Graph Analysis (12)
server/backend/database/doc_info.go (1)
api/yorkie/v1/resources.pb.go (3)
Schema(2586-2597)Schema(2612-2612)Schema(2627-2629)
client/options.go (1)
api/yorkie/v1/resources.pb.go (3)
Schema(2586-2597)Schema(2612-2612)Schema(2627-2629)
client/client.go (2)
api/yorkie/v1/resources.pb.go (3)
Schema(2586-2597)Schema(2612-2612)Schema(2627-2629)api/converter/from_pb.go (1)
FromRules(987-993)
server/rpc/connecthelper/status.go (3)
api/converter/from_pb.go (1)
ErrInvalidSchemaKey(42-42)server/backend/database/database.go (5)
ErrSchemaNotFound(66-66)ErrProjectAlreadyExists(33-33)ErrProjectNameAlreadyExists(60-60)ErrUserAlreadyExists(42-42)ErrSchemaAlreadyExists(69-69)server/backend/pubsub/pubsub.go (1)
ErrAlreadyConnected(39-39)
server/backend/database/schema_info.go (2)
api/types/schema.go (2)
Rule(24-28)Schema(30-47)api/converter/to_pb.go (1)
ToSchema(632-640)
api/types/schema.go (1)
api/yorkie/v1/resources.pb.go (3)
Rule(2673-2680)Rule(2695-2695)Rule(2710-2712)
test/integration/admin_test.go (5)
admin/client.go (2)
Dial(110-121)New(80-107)client/client.go (2)
Dial(183-194)New(132-180)test/helper/helper.go (1)
TestDocKey(344-373)server/schemas/schemas.go (2)
CreateSchema(27-42)RemoveSchema(107-115)api/yorkie/v1/resources.pb.go (3)
Rule(2673-2680)Rule(2695-2695)Rule(2710-2712)
api/types/project.go (1)
api/yorkie/v1/resources.pb.go (3)
Project(1639-1659)Project(1674-1674)Project(1689-1691)
api/types/create_schema_fields.go (1)
internal/validation/validation.go (5)
Validate(185-221)ValidateStruct(224-239)RegisterValidation(141-146)FieldLevel(100-100)RegisterTranslation(150-168)
pkg/schema/ruleset_validator_test.go (4)
api/yorkie/v1/resources.pb.go (3)
Rule(2673-2680)Rule(2695-2695)Rule(2710-2712)test/helper/helper.go (1)
TestDocKey(344-373)pkg/schema/ruleset_validator.go (2)
ValidateYorkieRuleset(41-55)ValidationError(35-38)pkg/document/crdt/counter.go (1)
IntegerCnt(36-36)
api/converter/from_pb.go (2)
api/yorkie/v1/resources.pb.go (6)
Rule(2673-2680)Rule(2695-2695)Rule(2710-2712)Schema(2586-2597)Schema(2612-2612)Schema(2627-2629)api/types/schema.go (2)
Rule(24-28)Schema(30-47)
server/backend/database/mongo/client.go (6)
server/documents/documents.go (1)
UpdateDocInfoSchema(348-355)api/types/resource_ref_key.go (1)
DocRefKey(24-27)server/backend/database/mongo/indexes.go (2)
ColDocuments(36-36)ColSchemas(44-44)server/backend/database/database.go (3)
ErrDocumentNotFound(48-48)ErrSchemaAlreadyExists(69-69)ErrSchemaNotFound(66-66)api/types/schema.go (1)
Rule(24-28)server/backend/database/schema_info.go (1)
SchemaInfo(26-47)
🔇 Additional comments (38)
server/backend/database/doc_info.go (1)
85-86: DeepCopy update looks correctThe new field is copied, preventing accidental loss of schema metadata on clones.
api/types/project_test.go (1)
100-110: Test correctly updated to new method nameAssertions still verify both the success and limit-exceeded cases; nothing further required.
client/options.go (1)
121-124: Option helper LGTM
WithSchemafollows the existing option pattern and is concise.api/types/project.go (1)
133-140: Inclusive limit check looks correct – just flagging for double-check
count >= MaxAttachmentsPerDocumentmeans callers must invokeCheckAttachmentLimitbefore adding the new attachment.
Confirm all call-sites follow that order; otherwise, the limit will be exceeded by one.server/backend/database/memory/indexes.go (1)
256-289: 👍 Comprehensive indexes for the newschemastableThe unique compound index on
(ProjectID, Name, Version)enforces versioned uniqueness while allowing multiple versions — good design.server/backend/database/mongo/indexes.go (1)
43-45: Shard-key ordering differs from the other collectionsEvery other collection uses
{project_id, …}as prefix to make the first key the shard key.
Keep the same order (project_idfirst) inColSchemasto avoid cross-shard fan-out queries.
If that was deliberate (e.g. separate shard key), please add a comment.api/docs/yorkie/v1/yorkie.openapi.yaml (1)
339-343: LGTM! OpenAPI schema changes are well-structured.The schema additions to the OpenAPI specification correctly represent the new schema attachment functionality:
- Optional
schemafield inAttachDocumentRequestfor specifying schema during attachmentschemaRulesarray inAttachDocumentResponseto return applicable rulesRuleobject definition withpathandtypefieldsAll additions follow the existing patterns and conventions in the OpenAPI spec.
Also applies to: 366-373, 1407-1422
api/converter/to_pb.go (1)
619-649: LGTM! Conversion functions follow established patterns.The new schema conversion functions are well-implemented:
ToRules: Simple and direct conversion of rule sliceToSchema: Properly converts all fields including timestamp usingtimestamppb.NewToSchemas: Follows the standard pattern for slice conversionThe implementation is consistent with other conversion functions in the file.
server/rpc/yorkie_server.go (1)
233-241: LGTM! Response correctly includes schema rules.The response properly includes schema rules when a schema is present, using the conversion function to transform the rules to the protobuf format.
api/types/create_schema_fields.go (1)
28-41: LGTM! Well-structured validation rules.The validation configuration is comprehensive:
- Reserved names check prevents conflicts (currently "new")
- Length constraints (2-30 chars) are reasonable
- Slug format ensures URL-safe schema names
- Required validation prevents empty names
pkg/document/document.go (1)
188-200: LGTM! Schema validation is properly integrated.The validation logic is well-implemented:
- Only validates non-presence changes when rules exist
- Properly clears clone state on validation failure
- Aggregates all validation errors into a single message
- Returns appropriate error type
admin/client.go (1)
471-526: LGTM! Well-implemented schema management methods.The new schema management methods follow the established patterns in the codebase and properly handle type conversions and error propagation.
pkg/schema/ruleset_validator_test.go (1)
1-189: Excellent test coverage for schema validation!The test file provides comprehensive coverage for all supported types and validation scenarios, including edge cases and Yorkie-specific types.
server/backend/database/database.go (2)
64-70: Well-defined error variables for schema operations.The new error variables follow the established naming convention and provide clear error messages.
234-398: Comprehensive schema management interface methods.The new schema-related methods provide a complete set of operations for schema lifecycle management, following the established patterns in the codebase.
server/backend/database/mongo/client.go (1)
1703-1730: Aggregation pipeline may omit index hint
ListSchemaInfosperforms a$sortonname,versionthen$group.
If the compound index(project_id, name, version)is not covered, this becomes O(n).
Consider addingoptions.Aggregate().SetHint(bson.D{{"project_id",1},{"name",1},{"version",-1}})or at least verifying the index exists duringensureIndexes.api/yorkie/v1/admin.proto (1)
242-248: Field numbering continuity confirmed – LGTMThe newly added messages start at field #242, avoiding collisions with existing fields.
server/backend/database/memory/database.go (4)
23-23: LGTM!The
sortpackage import is correctly added and used for sorting schema versions.
990-1021: LGTM!The implementation correctly updates the document schema with proper transaction handling and validation.
1637-1679: LGTM!The schema creation logic correctly handles duplicate prevention and follows the established patterns for entity creation.
1897-1917: LGTM!The implementation efficiently checks for schema usage by leveraging the index and only checking for the existence of results.
api/docs/yorkie/v1/admin.openapi.yaml (9)
49-60: Schema endpoint paths align with existing API patterns.
NewCreateSchema,GetSchema,GetSchemas,ListSchemas, andRemoveSchemapaths follow the established structure, use the correct HTTP method, and reference the appropriate request/response components.Also applies to: 121-132, 133-144, 205-216, 241-252
342-350: Request body components are correctly defined.
Each new request body undercomponents/requestBodiesfollows the naming convention (yorkie.v1.AdminService.X.yorkie.v1.XRequest) and points to the matching schema.Also applies to: 396-404, 405-413, 459-467, 486-494
577-585: Response components are correctly defined.
The added response definitions for schema operations mirror the existing pattern and reference the correctCreateSchemaResponse,GetSchemaResponse, etc.Also applies to: 631-639, 640-648, 694-702, 721-729
1076-1109: CreateSchema request/response schemas are well-structured.
CreateSchemaRequestincludes project name, rules array, and schema metadata;CreateSchemaResponseencapsulates the newSchemaobject.Also applies to: 1111-1122
1379-1398: GetSchema request/response schemas are accurate.
GetSchemaRequestcovers project name, schema name, and version;GetSchemaResponsereturns the correspondingSchemaobject.Also applies to: 1400-1411
1412-1428: GetSchemas request/response schemas are correct.
TheGetSchemasRequestandGetSchemasResponsedefinitions properly support filtering by project and (optional) schema name, returning an array ofSchemaobjects.Also applies to: 1429-1442
1662-1672: ListSchemas request/response schemas match the pattern.
ListSchemasRequestlists all schemas for a project;ListSchemasResponsereturns the collection underschemas.Also applies to: 1673-1687
2495-2516: RemoveSchema request/response schemas are properly defined.
RemoveSchemaRequestspecifies project, schema name, and version;RemoveSchemaResponseconfirms deletion.Also applies to: 2517-2521
2544-2559: Rule and Schema object definitions are comprehensive.
TheRuleschema captures path/type pairs andSchemaincludes ID, name, version, body, rules array, and timestamp—consistent with the resource model.Also applies to: 2560-2600
api/yorkie/v1/v1connect/admin.connect.go (8)
72-75: No issues – constant added correctly
AdminServiceUpdateProjectProcedurematches the proto definition and follows existing naming conventions; nothing further to flag.
102-114: Schema-procedure constants look correctAll five new procedure strings are well-formed (
/yorkie.v1.AdminService/<RPC>).
No duplicates detected in the constant block.
143-147: Client interface extended consistentlyNew schema-related methods appear in the client interface in alphabetical order and use the correct request/response types – good.
300-314: Struct fields aligned with interfaceThe concrete client now stores pointers for every new RPC. Field names follow existing pattern – all good.
359-362: Unary call delegate added
UpdateProjectsimply delegates to the generated client – consistent with other methods.
409-432: Schema RPC stubs mirror existing patternEach new method cleanly proxies to its corresponding
connect.Client. No issues spotted.
622-651: Router switch updated – coverage completeEvery newly added handler is referenced in the HTTP router; no fall-through or duplication issues found.
697-755: Unimplemented stubs syncedThe
UnimplementedAdminServiceHandlernow satisfies the expanded interface. Keeping this in sync prevents accidental compile-time breakage – nice.
There was a problem hiding this comment.
k6 Load Test 📊
This is a comparison result between the previous(0776a12) and the current commit(cfca662).
Change
| Metric | Previous | Current | Change |
|---|---|---|---|
| transaction_time.avg | 5845.94 | 5828.41 | 🟢 -0.30% |
| http_req_duration.avg | 274.38 | 274.75 | 🔴 +0.14% |
| http_req_duration.p(95) | 1383.06 | 1393.09 | 🔴 +0.73% |
| iteration_duration.avg | 5845.97 | 5828.45 | 🟢 -0.30% |
| data_received.count | 881,421,712 | 854,105,509 | 🟢 -3.10% |
| data_sent.count | 59,375,906 | 59,402,323 | 🔴 +0.04% |
Result
script: test/k6/presence.ts
scenarios: (100.00%) 1 scenario, 500 max VUs, 3m0s max duration (incl. graceful stop):
* default: Up to 500 looping VUs for 2m30s over 3 stages (gracefulRampDown: 30s, gracefulStop: 30s)
█ THRESHOLDS
control_doc_latency
✓ 'p(95)<500' p(95)=0
http_req_duration
✓ 'p(95)<10000' p(95)=1.39s
transaction_success_rate
✓ 'rate>0.99' rate=100.00%
█ TOTAL RESULTS
checks_total.......................: 126764 819.467823/s
checks_succeeded...................: 100.00% 126764 out of 126764
checks_failed......................: 0.00% 0 out of 126764
✓ status is 200
✓ response has valid body
CUSTOM
active_clients..........................................................: 9217 59.583438/s
attach_documents........................................................: 9217 59.583438/s
control_doc_latency.....................................................: avg=0 min=0 med=0 max=0 p(90)=0 p(95)=0
pushpulls...............................................................: 35731 230.983598/s
transaction_success_rate................................................: 100.00% 9217 out of 9217
transaction_time........................................................: avg=5828.409678 min=3020 med=5980 max=9290 p(90)=7802.4 p(95)=8075.2
HTTP
http_req_duration.......................................................: avg=274.75ms min=937.01µs med=21.1ms max=1.75s p(90)=1.29s p(95)=1.39s
{ expected_response:true }............................................: avg=274.75ms min=937.01µs med=21.1ms max=1.75s p(90)=1.29s p(95)=1.39s
http_req_failed.........................................................: 0.00% 0 out of 63382
http_reqs...............................................................: 63382 409.733912/s
EXECUTION
iteration_duration......................................................: avg=5.82s min=3.02s med=5.98s max=9.28s p(90)=7.8s p(95)=8.07s
iterations..............................................................: 9217 59.583438/s
vus.....................................................................: 1 min=1 max=500
vus_max.................................................................: 500 min=500 max=500
NETWORK
data_received...........................................................: 854 MB 5.5 MB/s
data_sent...............................................................: 59 MB 384 kB/s
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (11)
server/backend/database/schema_info.go (1)
49-60: Rules slice is shallow-copied in ToSchema method.The Rules slice is shallow-copied, which could cause data races if SchemaInfo.Rules is mutated concurrently.
test/integration/schema_test.go (6)
82-92: Add error handling for client deactivation.
109-141: Add client cleanup at the end of the test.The test creates two clients but doesn't deactivate them before closing.
143-163: Add client cleanup at the end of the test.Missing deactivation calls for both clients.
187-188: Add error handling for client deactivation.
228-230: Add error handling for client deactivation calls.
275-276: Add error handling for client deactivation.server/backend/database/memory/database.go (4)
1701-1725: Add DeepCopy to prevent unintended mutations.The method returns the raw schema object from the database without creating a copy.
1727-1756: Add DeepCopy to prevent unintended mutations.The method appends raw schema objects without creating copies.
1758-1784: Add DeepCopy to prevent unintended mutations.The method stores raw schema objects in the map without creating copies.
1786-1816: Fix receiver type and add missing transaction commit.The method has two issues previously identified:
- Uses value receiver instead of pointer receiver
- Missing transaction commit after deletion
🧹 Nitpick comments (2)
server/backend/database/memory/database.go (1)
1657-1699: Consider returning a deep copy for consistency.While the newly created object is safe to return as-is, other methods in this codebase consistently return deep copies. Consider returning
info.DeepCopy()instead ofinfofor consistency.txn.Commit() - return info, nil + return info.DeepCopy(), nilapi/docs/yorkie/v1/admin.openapi.yaml (1)
1663-1686: Define ListSchemasResponse schema
Theschemasarray lacks amaxItemslimit, which may lead to very large payloads. Adding amaxItemsconstraint is recommended.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (20)
admin/client.go(1 hunks)api/converter/from_pb.go(3 hunks)api/docs/yorkie/v1/admin.openapi.yaml(69 hunks)api/docs/yorkie/v1/cluster.openapi.yaml(5 hunks)api/docs/yorkie/v1/resources.openapi.yaml(71 hunks)api/docs/yorkie/v1/yorkie.openapi.yaml(52 hunks)api/types/create_schema_fields.go(1 hunks)api/types/schema.go(1 hunks)client/client.go(2 hunks)pkg/document/document.go(5 hunks)server/backend/database/database.go(3 hunks)server/backend/database/memory/database.go(5 hunks)server/backend/database/mongo/client.go(3 hunks)server/backend/database/schema_info.go(1 hunks)server/documents/documents.go(1 hunks)server/rpc/admin_server.go(2 hunks)server/rpc/connecthelper/status.go(4 hunks)server/rpc/yorkie_server.go(4 hunks)test/integration/admin_test.go(1 hunks)test/integration/schema_test.go(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- test/integration/admin_test.go
- api/docs/yorkie/v1/cluster.openapi.yaml
🚧 Files skipped from review as they are similar to previous changes (13)
- server/documents/documents.go
- server/rpc/connecthelper/status.go
- client/client.go
- server/rpc/yorkie_server.go
- api/types/schema.go
- admin/client.go
- pkg/document/document.go
- api/converter/from_pb.go
- api/docs/yorkie/v1/yorkie.openapi.yaml
- api/types/create_schema_fields.go
- server/rpc/admin_server.go
- server/backend/database/database.go
- server/backend/database/mongo/client.go
🧰 Additional context used
🪛 Checkov (3.2.334)
api/docs/yorkie/v1/admin.openapi.yaml
[MEDIUM] 942-950: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
api/docs/yorkie/v1/resources.openapi.yaml
[MEDIUM] 191-199: Ensure that arrays have a maximum number of items
(CKV_OPENAPI_21)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: complex-test
- GitHub Check: build
- GitHub Check: bench
- GitHub Check: load-test
🔇 Additional comments (18)
api/docs/yorkie/v1/resources.openapi.yaml (1)
1512-1567: LGTM!The new schema definitions for
yorkie.v1.Ruleandyorkie.v1.Schemaare well-structured and properly integrate with the existing OpenAPI specification. The schema validation feature is clearly represented with appropriate field types and references.api/docs/yorkie/v1/admin.openapi.yaml (17)
3-3: Update project description
The expanded description underinfo.descriptionadds helpful context about Yorkie’s purpose.
8-11: Define API servers
Theserversblock now clearly lists both production and local endpoints.
17-24: Align OpenAPI refs for ChangePassword
Request and response$refpaths have been updated to match the new Connect naming convention.
29-36: Align OpenAPI refs for CreateDocument
The$refupdates here are consistent with the rest of the spec.
41-48: Align OpenAPI refs for CreateProject
These$refchanges mirror the pattern used elsewhere and look good.
49-60: Add CreateSchema endpoint
NewCreateSchemaoperation is wired up correctly with requestBody, responses, and tags.
113-120: Align OpenAPI refs for GetProjectStats
TheGetProjectStatspayload references have been updated consistently.
121-132: Add GetSchema endpoint
GetSchemais defined correctly with matching request and response schemas.
133-144: Add GetSchemas endpoint
GetSchemasoperation is properly configured and consistent.
205-216: Add ListSchemas endpoint
ListSchemashas been integrated with the correct$refpointers and tagging.
241-252: Add RemoveSchema endpoint
RemoveSchemais wired up correctly; request and response references are in place.
342-350: Add CreateSchema requestBody
TheCreateSchemaRequestreference in components/requestBodies is accurate and required.
2495-2513: Define RemoveSchemaRequest schema
The shape ofRemoveSchemaRequestis correct and matches the RPC definition.
721-729: Define RemoveSchemaResponse schema
The response schema forRemoveSchemais properly specified.
2544-2560: Define Rule schema
TheRuleobject correctly captures path and type for validation rules.
2561-2599: Define Schema schema
Schemametadata and structure (body, rules, version, etc.) are well modeled.
3094-3096: Update AdminService tag description
The tag metadata foryorkie.v1.AdminServicehas been refined; looks good.
There was a problem hiding this comment.
Go Benchmark Analysis 📊
This is a comparison result between the previous(0776a12) and the current commit(cfca662).
Significant Changes (≥20% difference)
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| BenchmarkVersionVector/clients_100/ (7_pushpull_after_detach(ms)) | 8.00 ms | 6.00 ms | 🟢 -25.00% |
Key Observations 🔍
- Significant improvement in the
BenchmarkVersionVectorsuite, with theclients_100benchmark showing a substantial 25% decrease in response time. - Across various benchmarks, there is a mix of minor improvements and slight deterioration in performance metrics, with few exceeding the 20% threshold for significant changes.
- Most benchmarks show consistent performance or minor fluctuations, indicating overall stability in the system.
Clock Analysis
Lamport vs VersionVector
BenchmarkVersionVector Test
Lamport (v0.5.2)
| Metric | 10 clients | 100 clients | 1000 clients |
|---|---|---|---|
| Total Operation Time | 84.96 ms | 793.94 ms | 34.79 s |
| Memory Allocations | 35.11 MB | 219.92 MB | 4.91 GB |
| Number of Allocations (allocs/op) | 69,271 | 1,246,728 | 81,485,288 |
| ChangePack Size | 138.0 B | 137.0 B | 141.0 B |
| Snapshot Size | 379.0 B | 3.08 KB | 30.08 KB |
| Push-Pull Time | 2.0 ms | 1.5 ms | 4.0 ms |
| Attach Time | 4.5 ms | 11.0 ms | 31.0 ms |
| ChangePack After Detach | 138.0 B | 140.0 B | 141.0 B |
| Snapshot After Detach | 136.0 B | 137.0 B | 139.0 B |
| Push-Pull After Detach | 2.5 ms | 5.0 ms | 9.5 ms |
Version Vector (current)
| Metric | 10 clients | 100 clients | 1000 clients |
|---|---|---|---|
| Total Operation Time | 128.71 ms | 1.08 s | 14.42 s |
| Memory Allocations | 7.03 MB | 77.73 MB | 1.97 GB |
| Number of Allocations (allocs/op) | 57,980 | 711,595 | 32,363,979 |
| ChangePack Size | 202.00 B | 202.00 B | 203.00 B |
| Snapshot Size | 399.00 B | 3.10 KB | 30.10 KB |
| Push-Pull Time | 5.00 ms | 6.00 ms | 5.00 ms |
| Attach Time | 5.00 ms | 7.00 ms | 22.00 ms |
| ChangePack After Detach | 262.00 B | 263.00 B | 263.00 B |
| Snapshot After Detach | 156.00 B | 156.00 B | 156.00 B |
| Push-Pull After Detach | 5.00 ms | 8.00 ms | 5.00 ms |
BenchmarkSyncConcurrency Test
| Metric | Clients | Lamport (v0.5.2) | Version Vector (current) |
|---|---|---|---|
| Total Operation Time | 1-100-10-10 | 7.48 s | 11.55 s |
| 100-100-10-10 | 9.62 s | 12.64 s | |
| 300_100-10-10 | 14.77 s | 15.14 s | |
| Memory Allocations | 1-100-10-10 | 1.15 GB | 7.54 GB |
| 100-100-10-10 | 1.45 GB | 7.69 GB | |
| 300_100-10-10 | 2.19 GB | 7.99 GB | |
| Number of Allocations (allocs/op) | 1-100-10-10 | 17,107,766 | 157,749,989 |
| 100-100-10-10 | 20,084,480 | 159,757,164 | |
| 300_100-10-10 | 30,359,215 | 164,863,299 |
Summary
- In the Version Vector tests, we observe improvements in total operation time with increasing clients for both Lamport and Version Vector, but Version Vector consistently outperforms Lamport in terms of faster total operation times.
- Memory allocations increase significantly with the number of clients in both systems, with Version Vector showing higher memory consumption across all client scales.
- The number of allocations per operation shows a similar trend, with Version Vector requiring more allocations per operation compared to Lamport.
- Version Vector demonstrates better scalability and efficiency for higher client counts in terms of total operation time and memory allocations compared to Lamport.
- SyncConcurrency tests highlight that Version Vector generally requires more memory and allocation resources compared to Lamport for different concurrency levels, indicating potential bottlenecks in highly concurrent scenarios.
Detailed Test Results
BenchmarkDeletionConcurrency
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| concurrent_text_delete_range_100/ (ns/op) | 867.24 ms | 915.38 ms | 🔴 +5.55% |
| concurrent_text_delete_range_100/ (B/op) | 62.85 MB | 62.65 MB | 🟢 -0.32% |
| concurrent_text_delete_range_100/ (allocs/op) | 752,498 allocs | 752,465 allocs | ⚪ 0% |
| concurrent_text_delete_range_1000/ (ns/op) | 7.20 s | 7.21 s | 🔴 +0.07% |
| concurrent_text_delete_range_1000/ (B/op) | 375.54 MB | 376.61 MB | 🔴 +0.29% |
| concurrent_text_delete_range_1000/ (allocs/op) | 7,282,403 allocs | 7,283,424 allocs | 🔴 +0.01% |
| concurrent_tree_delete_range_100/ (ns/op) | 887.23 ms | 879.44 ms | 🟢 -0.88% |
| concurrent_tree_delete_range_100/ (B/op) | 69.03 MB | 67.99 MB | 🟢 -1.51% |
| concurrent_tree_delete_range_100/ (allocs/op) | 795,978 allocs | 795,926 allocs | ⚪ 0% |
| concurrent_tree_delete_range_1000/ (ns/op) | 7.88 s | 7.84 s | 🟢 -0.46% |
| concurrent_tree_delete_range_1000/ (B/op) | 905.70 MB | 907.16 MB | 🔴 +0.16% |
| concurrent_tree_delete_range_1000/ (allocs/op) | 7,654,691 allocs | 7,654,180 allocs | ⚪ 0% |
| concurrent_text_edit_delete_all_100/ (ns/op) | 753.39 ms | 756.13 ms | 🔴 +0.36% |
| concurrent_text_edit_delete_all_100/ (B/op) | 53.03 MB | 54.12 MB | 🔴 +2.06% |
| concurrent_text_edit_delete_all_100/ (allocs/op) | 635,038 allocs | 635,116 allocs | 🔴 +0.01% |
| concurrent_text_edit_delete_all_1000/ (ns/op) | 5.98 s | 5.97 s | 🟢 -0.18% |
| concurrent_text_edit_delete_all_1000/ (B/op) | 325.74 MB | 321.83 MB | 🟢 -1.20% |
| concurrent_text_edit_delete_all_1000/ (allocs/op) | 5,940,978 allocs | 5,940,677 allocs | ⚪ 0% |
| concurrent_tree_edit_delete_all_100/ (ns/op) | 779.73 ms | 777.16 ms | 🟢 -0.33% |
| concurrent_tree_edit_delete_all_100/ (B/op) | 84.51 MB | 85.40 MB | 🔴 +1.06% |
| concurrent_tree_edit_delete_all_100/ (allocs/op) | 873,581 allocs | 873,654 allocs | ⚪ 0% |
| concurrent_tree_edit_delete_all_1000/ (ns/op) | 6.58 s | 6.55 s | 🟢 -0.42% |
| concurrent_tree_edit_delete_all_1000/ (B/op) | 723.54 MB | 720.77 MB | 🟢 -0.38% |
| concurrent_tree_edit_delete_all_1000/ (allocs/op) | 6,407,676 allocs | 6,407,303 allocs | ⚪ 0% |
BenchmarkDocument
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| constructor_test/ (ns/op) | 1547.00 ns | 1718.00 ns | 🔴 +11.05% |
| constructor_test/ (B/op) | 1.56 KB | 1.58 KB | 🔴 +1.02% |
| constructor_test/ (allocs/op) | 27 allocs | 27 allocs | ⚪ 0% |
| status_test/ (ns/op) | 1169.00 ns | 1242.00 ns | 🔴 +6.24% |
| status_test/ (B/op) | 1.53 KB | 1.54 KB | 🔴 +1.05% |
| status_test/ (allocs/op) | 25 allocs | 25 allocs | ⚪ 0% |
| equals_test/ (ns/op) | 8149.00 ns | 8874.00 ns | 🔴 +8.90% |
| equals_test/ (B/op) | 8.22 KB | 8.27 KB | 🔴 +0.58% |
| equals_test/ (allocs/op) | 138 allocs | 138 allocs | ⚪ 0% |
| nested_update_test/ (ns/op) | 17346.00 ns | 18492.00 ns | 🔴 +6.61% |
| nested_update_test/ (B/op) | 12.81 KB | 12.83 KB | 🔴 +0.12% |
| nested_update_test/ (allocs/op) | 266 allocs | 266 allocs | ⚪ 0% |
| delete_test/ (ns/op) | 23251.00 ns | 24591.00 ns | 🔴 +5.76% |
| delete_test/ (B/op) | 16.37 KB | 16.39 KB | 🔴 +0.10% |
| delete_test/ (allocs/op) | 347 allocs | 347 allocs | ⚪ 0% |
| object_test/ (ns/op) | 8835.00 ns | 9304.00 ns | 🔴 +5.31% |
| object_test/ (B/op) | 7.38 KB | 7.39 KB | 🔴 +0.22% |
| object_test/ (allocs/op) | 122 allocs | 122 allocs | ⚪ 0% |
| array_test/ (ns/op) | 29274.00 ns | 30729.00 ns | 🔴 +4.97% |
| array_test/ (B/op) | 12.66 KB | 12.67 KB | 🔴 +0.13% |
| array_test/ (allocs/op) | 281 allocs | 281 allocs | ⚪ 0% |
| text_test/ (ns/op) | 33033.00 ns | 34370.00 ns | 🔴 +4.05% |
| text_test/ (B/op) | 15.48 KB | 15.50 KB | 🔴 +0.10% |
| text_test/ (allocs/op) | 502 allocs | 502 allocs | ⚪ 0% |
| text_composition_test/ (ns/op) | 31575.00 ns | 33741.00 ns | 🔴 +6.86% |
| text_composition_test/ (B/op) | 16.95 KB | 16.97 KB | 🔴 +0.09% |
| text_composition_test/ (allocs/op) | 488 allocs | 488 allocs | ⚪ 0% |
| rich_text_test/ (ns/op) | 87704.00 ns | 91560.00 ns | 🔴 +4.40% |
| rich_text_test/ (B/op) | 39.00 KB | 39.02 KB | 🔴 +0.04% |
| rich_text_test/ (allocs/op) | 1,187 allocs | 1,187 allocs | ⚪ 0% |
| counter_test/ (ns/op) | 18166.00 ns | 18714.00 ns | 🔴 +3.02% |
| counter_test/ (B/op) | 12.41 KB | 12.43 KB | 🔴 +0.13% |
| counter_test/ (allocs/op) | 255 allocs | 255 allocs | ⚪ 0% |
| text_edit_gc_100/ (ns/op) | 1.43 ms | 1.45 ms | 🔴 +1.80% |
| text_edit_gc_100/ (B/op) | 810.05 KB | 810.06 KB | ⚪ 0% |
| text_edit_gc_100/ (allocs/op) | 16,785 allocs | 16,785 allocs | ⚪ 0% |
| text_edit_gc_1000/ (ns/op) | 54.62 ms | 55.43 ms | 🔴 +1.48% |
| text_edit_gc_1000/ (B/op) | 46.29 MB | 46.29 MB | ⚪ 0% |
| text_edit_gc_1000/ (allocs/op) | 180,597 allocs | 180,592 allocs | ⚪ 0% |
| text_split_gc_100/ (ns/op) | 2.14 ms | 2.19 ms | 🔴 +1.98% |
| text_split_gc_100/ (B/op) | 1.53 MB | 1.53 MB | ⚪ 0% |
| text_split_gc_100/ (allocs/op) | 15,553 allocs | 15,551 allocs | 🟢 -0.01% |
| text_split_gc_1000/ (ns/op) | 131.58 ms | 137.24 ms | 🔴 +4.30% |
| text_split_gc_1000/ (B/op) | 137.29 MB | 137.29 MB | ⚪ 0% |
| text_split_gc_1000/ (allocs/op) | 181,001 allocs | 180,994 allocs | ⚪ 0% |
| text_100/ (ns/op) | 236086.00 ns | 239418.00 ns | 🔴 +1.41% |
| text_100/ (B/op) | 113.21 KB | 113.23 KB | 🔴 +0.01% |
| text_100/ (allocs/op) | 4,984 allocs | 4,984 allocs | ⚪ 0% |
| text_1000/ (ns/op) | 2.56 ms | 2.60 ms | 🔴 +1.71% |
| text_1000/ (B/op) | 1.08 MB | 1.08 MB | ⚪ 0% |
| text_1000/ (allocs/op) | 49,087 allocs | 49,087 allocs | ⚪ 0% |
| array_1000/ (ns/op) | 1.29 ms | 1.33 ms | 🔴 +3.04% |
| array_1000/ (B/op) | 1.13 MB | 1.13 MB | ⚪ 0% |
| array_1000/ (allocs/op) | 12,882 allocs | 12,882 allocs | ⚪ 0% |
| array_10000/ (ns/op) | 14.27 ms | 14.48 ms | 🔴 +1.46% |
| array_10000/ (B/op) | 10.29 MB | 10.29 MB | ⚪ 0% |
| array_10000/ (allocs/op) | 130,737 allocs | 130,734 allocs | ⚪ 0% |
| array_gc_100/ (ns/op) | 139640.00 ns | 142182.00 ns | 🔴 +1.82% |
| array_gc_100/ (B/op) | 104.26 KB | 104.28 KB | 🔴 +0.02% |
| array_gc_100/ (allocs/op) | 1,369 allocs | 1,369 allocs | ⚪ 0% |
| array_gc_1000/ (ns/op) | 1.50 ms | 1.51 ms | 🔴 +0.80% |
| array_gc_1000/ (B/op) | 1.18 MB | 1.18 MB | 🔴 +0.02% |
| array_gc_1000/ (allocs/op) | 13,928 allocs | 13,929 allocs | ⚪ 0% |
| counter_1000/ (ns/op) | 204089.00 ns | 206997.00 ns | 🔴 +1.42% |
| counter_1000/ (B/op) | 194.34 KB | 194.36 KB | ⚪ 0% |
| counter_1000/ (allocs/op) | 5,772 allocs | 5,772 allocs | ⚪ 0% |
| counter_10000/ (ns/op) | 2.22 ms | 2.24 ms | 🔴 +0.79% |
| counter_10000/ (B/op) | 2.23 MB | 2.23 MB | ⚪ 0% |
| counter_10000/ (allocs/op) | 59,779 allocs | 59,779 allocs | ⚪ 0% |
| object_1000/ (ns/op) | 1.51 ms | 1.58 ms | 🔴 +4.21% |
| object_1000/ (B/op) | 1.48 MB | 1.48 MB | 🟢 -0.02% |
| object_1000/ (allocs/op) | 10,927 allocs | 10,927 allocs | ⚪ 0% |
| object_10000/ (ns/op) | 16.86 ms | 17.14 ms | 🔴 +1.66% |
| object_10000/ (B/op) | 12.75 MB | 12.75 MB | 🔴 +0.03% |
| object_10000/ (allocs/op) | 111,222 allocs | 111,234 allocs | 🔴 +0.01% |
| tree_100/ (ns/op) | 743732.00 ns | 754549.00 ns | 🔴 +1.45% |
| tree_100/ (B/op) | 524.12 KB | 524.14 KB | ⚪ 0% |
| tree_100/ (allocs/op) | 4,721 allocs | 4,721 allocs | ⚪ 0% |
| tree_1000/ (ns/op) | 49.98 ms | 53.67 ms | 🔴 +7.38% |
| tree_1000/ (B/op) | 43.74 MB | 43.74 MB | ⚪ 0% |
| tree_1000/ (allocs/op) | 46,130 allocs | 46,130 allocs | ⚪ 0% |
| tree_10000/ (ns/op) | 6.71 s | 6.81 s | 🔴 +1.54% |
| tree_10000/ (B/op) | 4.30 GB | 4.30 GB | ⚪ 0% |
| tree_10000/ (allocs/op) | 460,186 allocs | 460,189 allocs | ⚪ 0% |
| tree_edit_gc_100/ (ns/op) | 2.67 ms | 2.75 ms | 🔴 +3.10% |
| tree_edit_gc_100/ (B/op) | 2.40 MB | 2.40 MB | ⚪ 0% |
| tree_edit_gc_100/ (allocs/op) | 11,568 allocs | 11,568 allocs | ⚪ 0% |
| tree_edit_gc_1000/ (ns/op) | 207.18 ms | 223.73 ms | 🔴 +7.99% |
| tree_edit_gc_1000/ (B/op) | 213.99 MB | 213.99 MB | ⚪ 0% |
| tree_edit_gc_1000/ (allocs/op) | 115,151 allocs | 115,148 allocs | ⚪ 0% |
| tree_split_gc_100/ (ns/op) | 2.04 ms | 2.09 ms | 🔴 +2.33% |
| tree_split_gc_100/ (B/op) | 1.62 MB | 1.62 MB | ⚪ 0% |
| tree_split_gc_100/ (allocs/op) | 9,605 allocs | 9,605 allocs | ⚪ 0% |
| tree_split_gc_1000/ (ns/op) | 146.21 ms | 158.62 ms | 🔴 +8.49% |
| tree_split_gc_1000/ (B/op) | 149.90 MB | 149.90 MB | ⚪ 0% |
| tree_split_gc_1000/ (allocs/op) | 107,755 allocs | 107,757 allocs | ⚪ 0% |
BenchmarkDocumentDeletion
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| single_text_delete_all_10000/ (ns/op) | 18.59 ms | 18.02 ms | 🟢 -3.06% |
| single_text_delete_all_10000/ (B/op) | 10.82 MB | 10.82 MB | 🔴 +0.03% |
| single_text_delete_all_10000/ (allocs/op) | 66,135 allocs | 66,131 allocs | ⚪ 0% |
| single_text_delete_all_100000/ (ns/op) | 327.47 ms | 301.76 ms | 🟢 -7.85% |
| single_text_delete_all_100000/ (B/op) | 107.97 MB | 107.93 MB | 🟢 -0.04% |
| single_text_delete_all_100000/ (allocs/op) | 666,221 allocs | 666,100 allocs | 🟢 -0.02% |
| single_tree_delete_all_1000/ (ns/op) | 50.76 ms | 53.66 ms | 🔴 +5.70% |
| single_tree_delete_all_1000/ (B/op) | 44.69 MB | 44.69 MB | ⚪ 0% |
| single_tree_delete_all_1000/ (allocs/op) | 57,207 allocs | 57,204 allocs | ⚪ 0% |
| single_text_delete_range_100/ (ns/op) | 435506.00 ns | 442727.00 ns | 🔴 +1.66% |
| single_text_delete_range_100/ (B/op) | 244.89 KB | 244.90 KB | ⚪ 0% |
| single_text_delete_range_100/ (allocs/op) | 6,974 allocs | 6,974 allocs | ⚪ 0% |
| single_text_delete_range_1000/ (ns/op) | 8.69 ms | 8.86 ms | 🔴 +2.00% |
| single_text_delete_range_1000/ (B/op) | 6.39 MB | 6.39 MB | ⚪ 0% |
| single_text_delete_range_1000/ (allocs/op) | 72,370 allocs | 72,370 allocs | ⚪ 0% |
| single_tree_delete_range_100/ (ns/op) | 958344.00 ns | 975270.00 ns | 🔴 +1.77% |
| single_tree_delete_range_100/ (B/op) | 711.64 KB | 711.62 KB | ⚪ 0% |
| single_tree_delete_range_100/ (allocs/op) | 6,292 allocs | 6,292 allocs | ⚪ 0% |
| single_tree_delete_range_1000/ (ns/op) | 59.04 ms | 61.99 ms | 🔴 +4.99% |
| single_tree_delete_range_1000/ (B/op) | 54.54 MB | 54.54 MB | ⚪ 0% |
| single_tree_delete_range_1000/ (allocs/op) | 62,435 allocs | 62,436 allocs | ⚪ 0% |
BenchmarkRPC
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| client_to_server/ (ns/op) | 295.05 ms | 294.85 ms | 🟢 -0.07% |
| client_to_server/ (B/op) | 12.96 MB | 12.12 MB | 🟢 -6.47% |
| client_to_server/ (allocs/op) | 178,248 allocs | 178,179 allocs | 🟢 -0.04% |
| client_to_client_via_server/ (ns/op) | 214.98 ms | 215.86 ms | 🔴 +0.41% |
| client_to_client_via_server/ (B/op) | 19.83 MB | 20.82 MB | 🔴 +4.99% |
| client_to_client_via_server/ (allocs/op) | 295,923 allocs | 295,922 allocs | ⚪ 0% |
| attach_large_document/ (ns/op) | 1.34 s | 1.34 s | 🔴 +0.48% |
| attach_large_document/ (B/op) | 1.88 GB | 1.88 GB | 🟢 -0.05% |
| attach_large_document/ (allocs/op) | 10,902 allocs | 10,777 allocs | 🟢 -1.15% |
| adminCli_to_server/ (ns/op) | 573.27 ms | 570.72 ms | 🟢 -0.44% |
| adminCli_to_server/ (B/op) | 22.45 MB | 21.55 MB | 🟢 -4.02% |
| adminCli_to_server/ (allocs/op) | 317,785 allocs | 317,781 allocs | ⚪ 0% |
BenchmarkLocker
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| (ns/op) | 83.63 ns | 83.55 ns | 🟢 -0.10% |
| (B/op) | 32.00 B | 32.00 B | ⚪ 0% |
| (allocs/op) | 1 allocs | 1 allocs | ⚪ 0% |
BenchmarkLockerParallel
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| (ns/op) | 47.10 ns | 46.42 ns | 🟢 -1.44% |
| (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
BenchmarkLockerMoreKeys
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| (ns/op) | 179.70 ns | 185.90 ns | 🔴 +3.45% |
| (B/op) | 31.00 B | 30.00 B | 🟢 -3.23% |
| (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
BenchmarkRWLocker
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| RWLock_rate_2/ (ns/op) | 50.40 ns | 49.45 ns | 🟢 -1.88% |
| RWLock_rate_2/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| RWLock_rate_2/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| RWLock_rate_10/ (ns/op) | 44.82 ns | 56.99 ns | 🔴 +27.15% |
| RWLock_rate_10/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| RWLock_rate_10/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| RWLock_rate_100/ (ns/op) | 61.05 ns | 60.03 ns | 🟢 -1.67% |
| RWLock_rate_100/ (B/op) | 2.00 B | 2.00 B | ⚪ 0% |
| RWLock_rate_100/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| RWLock_rate_1000/ (ns/op) | 89.21 ns | 88.73 ns | 🟢 -0.54% |
| RWLock_rate_1000/ (B/op) | 7.00 B | 8.00 B | 🔴 +14.29% |
| RWLock_rate_1000/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
BenchmarkPresenceConcurrency
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| 0-100-10/ (ns/op) | 1.05 s | 1.05 s | 🟢 -0.28% |
| 0-100-10/ (B/op) | 306.23 MB | 307.41 MB | 🔴 +0.39% |
| 0-100-10/ (allocs/op) | 4,772,939 allocs | 4,777,185 allocs | 🔴 +0.09% |
| 100-100-10/ (ns/op) | 1.09 s | 1.07 s | 🟢 -1.32% |
| 100-100-10/ (B/op) | 333.43 MB | 324.05 MB | 🟢 -2.81% |
| 100-100-10/ (allocs/op) | 5,324,740 allocs | 5,321,667 allocs | 🟢 -0.06% |
| 300-100-10/ (ns/op) | 1.15 s | 1.15 s | 🔴 +0.78% |
| 300-100-10/ (B/op) | 379.87 MB | 385.52 MB | 🔴 +1.49% |
| 300-100-10/ (allocs/op) | 6,428,377 allocs | 6,429,303 allocs | 🔴 +0.01% |
BenchmarkChange
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| Push_10_Changes/ (ns/op) | 4.76 ms | 4.78 ms | 🔴 +0.41% |
| Push_10_Changes/ (B/op) | 146.58 KB | 147.10 KB | 🔴 +0.35% |
| Push_10_Changes/ (allocs/op) | 1,630 allocs | 1,632 allocs | 🔴 +0.12% |
| Push_100_Changes/ (ns/op) | 18.73 ms | 18.72 ms | 🟢 -0.07% |
| Push_100_Changes/ (B/op) | 776.24 KB | 768.53 KB | 🟢 -0.99% |
| Push_100_Changes/ (allocs/op) | 8,875 allocs | 8,872 allocs | 🟢 -0.03% |
| Push_1000_Changes/ (ns/op) | 150.42 ms | 151.73 ms | 🔴 +0.87% |
| Push_1000_Changes/ (B/op) | 7.26 MB | 7.31 MB | 🔴 +0.61% |
| Push_1000_Changes/ (allocs/op) | 83,260 allocs | 83,266 allocs | ⚪ 0% |
| Pull_10_Changes/ (ns/op) | 3.57 ms | 3.56 ms | 🟢 -0.05% |
| Pull_10_Changes/ (B/op) | 118.79 KB | 118.58 KB | 🟢 -0.17% |
| Pull_10_Changes/ (allocs/op) | 1,335 allocs | 1,332 allocs | 🟢 -0.22% |
| Pull_100_Changes/ (ns/op) | 5.52 ms | 5.56 ms | 🔴 +0.65% |
| Pull_100_Changes/ (B/op) | 347.96 KB | 348.17 KB | 🔴 +0.06% |
| Pull_100_Changes/ (allocs/op) | 4,970 allocs | 4,968 allocs | 🟢 -0.04% |
| Pull_1000_Changes/ (ns/op) | 12.34 ms | 12.65 ms | 🔴 +2.55% |
| Pull_1000_Changes/ (B/op) | 2.16 MB | 2.16 MB | ⚪ 0% |
| Pull_1000_Changes/ (allocs/op) | 43,592 allocs | 43,583 allocs | 🟢 -0.02% |
BenchmarkSnapshot
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| Push_3KB_snapshot/ (ns/op) | 22.22 ms | 22.22 ms | ⚪ 0% |
| Push_3KB_snapshot/ (B/op) | 1.07 MB | 1.07 MB | 🔴 +0.42% |
| Push_3KB_snapshot/ (allocs/op) | 11,398 allocs | 11,394 allocs | 🟢 -0.04% |
| Push_30KB_snapshot/ (ns/op) | 158.86 ms | 160.54 ms | 🔴 +1.06% |
| Push_30KB_snapshot/ (B/op) | 10.40 MB | 10.30 MB | 🟢 -0.92% |
| Push_30KB_snapshot/ (allocs/op) | 127,069 allocs | 127,645 allocs | 🔴 +0.45% |
| Pull_3KB_snapshot/ (ns/op) | 7.98 ms | 8.15 ms | 🔴 +2.19% |
| Pull_3KB_snapshot/ (B/op) | 1.06 MB | 1.06 MB | 🔴 +0.06% |
| Pull_3KB_snapshot/ (allocs/op) | 17,821 allocs | 17,823 allocs | 🔴 +0.01% |
| Pull_30KB_snapshot/ (ns/op) | 21.59 ms | 21.32 ms | 🟢 -1.24% |
| Pull_30KB_snapshot/ (B/op) | 8.85 MB | 8.85 MB | ⚪ 0% |
| Pull_30KB_snapshot/ (allocs/op) | 171,838 allocs | 171,834 allocs | ⚪ 0% |
BenchmarkSplayTree
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| stress_test_100000/ (ns/op) | 0.19 ns | 0.18 ns | 🟢 -5.47% |
| stress_test_100000/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| stress_test_100000/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| stress_test_200000/ (ns/op) | 0.36 ns | 0.37 ns | 🔴 +0.94% |
| stress_test_200000/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| stress_test_200000/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| stress_test_300000/ (ns/op) | 0.56 ns | 0.54 ns | 🟢 -4.79% |
| stress_test_300000/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| stress_test_300000/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| random_access_100000/ (ns/op) | 0.01 ns | 0.01 ns | 🔴 +2.46% |
| random_access_100000/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| random_access_100000/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| random_access_200000/ (ns/op) | 0.03 ns | 0.03 ns | 🔴 +2.11% |
| random_access_200000/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| random_access_200000/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| random_access_300000/ (ns/op) | 0.04 ns | 0.04 ns | 🔴 +0.87% |
| random_access_300000/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| random_access_300000/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
| editing_trace_bench/ (ns/op) | 0.00 ns | 0.00 ns | 🟢 -6.06% |
| editing_trace_bench/ (B/op) | 0.00 B | 0.00 B | ⚪ 0% |
| editing_trace_bench/ (allocs/op) | 0 allocs | 0 allocs | ⚪ 0% |
BenchmarkSync
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| memory_sync_10_test/ (ns/op) | 7063.00 ns | 7102.00 ns | 🔴 +0.55% |
| memory_sync_10_test/ (B/op) | 1.34 KB | 1.34 KB | ⚪ 0% |
| memory_sync_10_test/ (allocs/op) | 35 allocs | 35 allocs | ⚪ 0% |
| memory_sync_100_test/ (ns/op) | 54807.00 ns | 56299.00 ns | 🔴 +2.72% |
| memory_sync_100_test/ (B/op) | 9.52 KB | 9.52 KB | 🔴 +0.03% |
| memory_sync_100_test/ (allocs/op) | 268 allocs | 268 allocs | ⚪ 0% |
| memory_sync_1000_test/ (ns/op) | 598603.00 ns | 592937.00 ns | 🟢 -0.95% |
| memory_sync_1000_test/ (B/op) | 76.31 KB | 77.02 KB | 🔴 +0.92% |
| memory_sync_1000_test/ (allocs/op) | 2,125 allocs | 2,135 allocs | 🔴 +0.47% |
| memory_sync_10000_test/ (ns/op) | 7.70 ms | 7.41 ms | 🟢 -3.76% |
| memory_sync_10000_test/ (B/op) | 768.26 KB | 765.53 KB | 🟢 -0.35% |
| memory_sync_10000_test/ (allocs/op) | 20,587 allocs | 20,546 allocs | 🟢 -0.20% |
BenchmarkSyncConcurrency
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| 1-100-10/ (ns/op) | 11.49 s | 11.55 s | 🔴 +0.50% |
| 1-100-10/ (B/op) | 7.54 GB | 7.54 GB | ⚪ 0% |
| 1-100-10/ (allocs/op) | 157,730,169 allocs | 157,749,989 allocs | 🔴 +0.01% |
| 100-100-10/ (ns/op) | 12.63 s | 12.64 s | 🔴 +0.07% |
| 100-100-10/ (B/op) | 7.69 GB | 7.69 GB | 🟢 -0.01% |
| 100-100-10/ (allocs/op) | 159,927,282 allocs | 159,757,164 allocs | 🟢 -0.11% |
| 300_100-10/ (ns/op) | 15.20 s | 15.14 s | 🟢 -0.34% |
| 300_100-10/ (B/op) | 8.00 GB | 7.99 GB | 🟢 -0.09% |
| 300_100-10/ (allocs/op) | 164,956,765 allocs | 164,863,299 allocs | 🟢 -0.06% |
BenchmarkTextEditing
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| (ns/op) | 5.69 s | 5.73 s | 🔴 +0.79% |
| (B/op) | 3.89 GB | 3.89 GB | ⚪ 0% |
| (allocs/op) | 20,282,808 allocs | 20,282,806 allocs | ⚪ 0% |
BenchmarkTree
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| 10000_vertices_to_protobuf/ (ns/op) | 4.93 ms | 4.87 ms | 🟢 -1.05% |
| 10000_vertices_to_protobuf/ (B/op) | 6.68 MB | 6.68 MB | ⚪ 0% |
| 10000_vertices_to_protobuf/ (allocs/op) | 90,026 allocs | 90,026 allocs | ⚪ 0% |
| 10000_vertices_from_protobuf/ (ns/op) | 223.48 ms | 222.46 ms | 🟢 -0.45% |
| 10000_vertices_from_protobuf/ (B/op) | 442.14 MB | 442.15 MB | ⚪ 0% |
| 10000_vertices_from_protobuf/ (allocs/op) | 280,046 allocs | 280,046 allocs | ⚪ 0% |
| 20000_vertices_to_protobuf/ (ns/op) | 10.47 ms | 10.70 ms | 🔴 +2.15% |
| 20000_vertices_to_protobuf/ (B/op) | 13.53 MB | 13.53 MB | ⚪ 0% |
| 20000_vertices_to_protobuf/ (allocs/op) | 180,029 allocs | 180,029 allocs | ⚪ 0% |
| 20000_vertices_from_protobuf/ (ns/op) | 872.57 ms | 878.40 ms | 🔴 +0.67% |
| 20000_vertices_from_protobuf/ (B/op) | 1.70 GB | 1.70 GB | ⚪ 0% |
| 20000_vertices_from_protobuf/ (allocs/op) | 560,123 allocs | 560,122 allocs | ⚪ 0% |
| 30000_vertices_to_protobuf/ (ns/op) | 15.76 ms | 15.96 ms | 🔴 +1.25% |
| 30000_vertices_to_protobuf/ (B/op) | 19.94 MB | 19.94 MB | ⚪ 0% |
| 30000_vertices_to_protobuf/ (allocs/op) | 270,031 allocs | 270,030 allocs | ⚪ 0% |
| 30000_vertices_from_protobuf/ (ns/op) | 1.97 s | 2.01 s | 🔴 +2.40% |
| 30000_vertices_from_protobuf/ (B/op) | 3.75 GB | 3.75 GB | ⚪ 0% |
| 30000_vertices_from_protobuf/ (allocs/op) | 840,126 allocs | 840,127 allocs | ⚪ 0% |
BenchmarkVersionVector
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| clients_10/ (ns/op) | 128.82 ms | 128.71 ms | 🟢 -0.08% |
| clients_10/ (1_changepack(bytes)) | 202.00 B | 202.00 B | ⚪ 0% |
| clients_10/ (2_snapshot(bytes)) | 399.00 B | 399.00 B | ⚪ 0% |
| clients_10/ (3_pushpull(ms)) | 5.00 ms | 5.00 ms | ⚪ 0% |
| clients_10/ (4_attach(ms)) | 5.00 ms | 5.00 ms | ⚪ 0% |
| clients_10/ (5_changepack_after_detach(bytes)) | 262.00 B | 262.00 B | ⚪ 0% |
| clients_10/ (6_snapshot_after_detach(bytes)) | 156.00 B | 156.00 B | ⚪ 0% |
| clients_10/ (7_pushpull_after_detach(ms)) | 5.00 ms | 5.00 ms | ⚪ 0% |
| clients_10/ (B/op) | 6.81 MB | 7.03 MB | 🔴 +3.30% |
| clients_10/ (allocs/op) | 57,964 allocs | 57,980 allocs | 🔴 +0.03% |
| clients_100/ (ns/op) | 1.09 s | 1.08 s | 🟢 -0.27% |
| clients_100/ (1_changepack(bytes)) | 202.00 B | 202.00 B | ⚪ 0% |
| clients_100/ (2_snapshot(bytes)) | 3.10 KB | 3.10 KB | ⚪ 0% |
| clients_100/ (3_pushpull(ms)) | 5.00 ms | 5.00 ms | ⚪ 0% |
| clients_100/ (4_attach(ms)) | 7.00 ms | 7.00 ms | ⚪ 0% |
| clients_100/ (5_changepack_after_detach(bytes)) | 263.00 B | 263.00 B | ⚪ 0% |
| clients_100/ (6_snapshot_after_detach(bytes)) | 156.00 B | 156.00 B | ⚪ 0% |
| clients_100/ (7_pushpull_after_detach(ms)) | 8.00 ms | 6.00 ms | 🟢 -25.00% |
| clients_100/ (B/op) | 68.78 MB | 77.73 MB | 🔴 +13.02% |
| clients_100/ (allocs/op) | 711,305 allocs | 711,595 allocs | 🔴 +0.04% |
| clients_1000/ (ns/op) | 14.51 s | 14.42 s | 🟢 -0.61% |
| clients_1000/ (1_changepack(bytes)) | 203.00 B | 203.00 B | ⚪ 0% |
| clients_1000/ (2_snapshot(bytes)) | 30.10 KB | 30.10 KB | ⚪ 0% |
| clients_1000/ (3_pushpull(ms)) | 5.00 ms | 5.00 ms | ⚪ 0% |
| clients_1000/ (4_attach(ms)) | 27.00 ms | 22.00 ms | 🟢 -18.52% |
| clients_1000/ (5_changepack_after_detach(bytes)) | 263.00 B | 263.00 B | ⚪ 0% |
| clients_1000/ (6_snapshot_after_detach(bytes)) | 156.00 B | 156.00 B | ⚪ 0% |
| clients_1000/ (7_pushpull_after_detach(ms)) | 6.00 ms | 5.00 ms | 🟢 -16.67% |
| clients_1000/ (B/op) | 1.97 GB | 1.97 GB | ⚪ 0% |
| clients_1000/ (allocs/op) | 32,364,710 allocs | 32,363,979 allocs | ⚪ 0% |
BenchmarkWebhook
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| Send_10_Webhooks_to_10_Endpoints/ (ns/op) | 12.28 ms | 12.34 ms | 🔴 +0.49% |
| Send_10_Webhooks_to_10_Endpoints/ (B/op) | 808.47 KB | 808.47 KB | ⚪ 0% |
| Send_10_Webhooks_to_10_Endpoints/ (allocs/op) | 10,117 allocs | 10,117 allocs | ⚪ 0% |
| Send_100_Webhooks_to_10_Endpoints/ (ns/op) | 121.78 ms | 122.37 ms | 🔴 +0.49% |
| Send_100_Webhooks_to_10_Endpoints/ (B/op) | 8.08 MB | 8.08 MB | 🟢 -0.03% |
| Send_100_Webhooks_to_10_Endpoints/ (allocs/op) | 101,155 allocs | 101,152 allocs | ⚪ 0% |
| Send_10_Webhooks_to_100_Endpoints/ (ns/op) | 125.06 ms | 125.01 ms | 🟢 -0.05% |
| Send_10_Webhooks_to_100_Endpoints/ (B/op) | 8.28 MB | 8.28 MB | 🔴 +0.01% |
| Send_10_Webhooks_to_100_Endpoints/ (allocs/op) | 102,529 allocs | 102,529 allocs | ⚪ 0% |
| Send_100_Webhooks_to_100_Endpoints/ (ns/op) | 1.24 s | 1.24 s | 🔴 +0.05% |
| Send_100_Webhooks_to_100_Endpoints/ (B/op) | 82.36 MB | 82.36 MB | ⚪ 0% |
| Send_100_Webhooks_to_100_Endpoints/ (allocs/op) | 1,022,332 allocs | 1,022,272 allocs | ⚪ 0% |
| Send_10_Webhooks_to_1000_Endpoints/ (ns/op) | 2.77 s | 2.76 s | 🟢 -0.05% |
| Send_10_Webhooks_to_1000_Endpoints/ (B/op) | 209.70 MB | 209.69 MB | ⚪ 0% |
| Send_10_Webhooks_to_1000_Endpoints/ (allocs/op) | 1,716,485 allocs | 1,716,556 allocs | ⚪ 0% |
BenchmarkWebhookWithLimit
| Benchmark suite | Previous | Current | Change |
|---|---|---|---|
| Send_10_Webhooks_to_10_Endpoints_with_limit/ (ns/op) | 3.74 ms | 3.75 ms | 🔴 +0.19% |
| Send_10_Webhooks_to_10_Endpoints_with_limit/ (B/op) | 306.44 KB | 306.27 KB | 🟢 -0.05% |
| Send_10_Webhooks_to_10_Endpoints_with_limit/ (allocs/op) | 2,914 allocs | 2,913 allocs | 🟢 -0.03% |
| Send_100_Webhooks_to_10_Endpoints_with_limit/ (ns/op) | 4.04 ms | 4.02 ms | 🟢 -0.48% |
| Send_100_Webhooks_to_10_Endpoints_with_limit/ (B/op) | 428.88 KB | 428.84 KB | 🟢 -0.01% |
| Send_100_Webhooks_to_10_Endpoints_with_limit/ (allocs/op) | 4,714 allocs | 4,713 allocs | 🟢 -0.02% |
| Send_10_Webhooks_to_100_Endpoints_with_limit/ (ns/op) | 37.74 ms | 37.50 ms | 🟢 -0.64% |
| Send_10_Webhooks_to_100_Endpoints_with_limit/ (B/op) | 3.08 MB | 3.08 MB | ⚪ 0% |
| Send_10_Webhooks_to_100_Endpoints_with_limit/ (allocs/op) | 29,173 allocs | 29,163 allocs | 🟢 -0.03% |
| Send_100_Webhooks_to_100_Endpoints_with_limit/ (ns/op) | 40.21 ms | 40.16 ms | 🟢 -0.14% |
| Send_100_Webhooks_to_100_Endpoints_with_limit/ (B/op) | 4.37 MB | 4.37 MB | ⚪ 0% |
| Send_100_Webhooks_to_100_Endpoints_with_limit/ (allocs/op) | 47,193 allocs | 47,185 allocs | 🟢 -0.02% |
| Send_10_Webhooks_to_1000_Endpoints_with_limit/ (ns/op) | 364.81 ms | 369.04 ms | 🔴 +1.16% |
| Send_10_Webhooks_to_1000_Endpoints_with_limit/ (B/op) | 44.51 MB | 44.49 MB | 🟢 -0.03% |
| Send_10_Webhooks_to_1000_Endpoints_with_limit/ (allocs/op) | 380,103 allocs | 380,118 allocs | ⚪ 0% |
What this PR does / why we need it:
Enhance document attachment with schema validation
Which issue(s) this PR fixes:
Related #971
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation:
Checklist:
Summary by CodeRabbit
New Features
Bug Fixes
Tests
Documentation
Style