Conversation
|
✅ No conflicts with other open PRs targeting |
|
I see you updated files related to
|
| }); err != nil { | ||
| return nil, fmt.Errorf("failed to update settings: %w", err) | ||
| spec := j.CRESettingsSpec | ||
| configType := spec.ConfigType |
There was a problem hiding this comment.
cc @jmank88 are you OK with this extension? Soon we can also add the third type for offchain Capabilities Registry (FYI @vyzaldysanchez )
There was a problem hiding this comment.
I've refactored this a bit after @pavel-raykov 's suggestion. pls have a look
|
|
||
| switch { | ||
| case e.cfg.ShardResolver != nil: | ||
| shardID, found, resolveErr := e.cfg.ShardResolver.ResolveShard(ctx, e.cfg.WorkflowID, e.cfg.WorkflowOwner) |
There was a problem hiding this comment.
We need to include info on whether current shard is primary or backup for this workflow. Backup will still subscribe to triggers and collect trigger events but not execute by default (until a fallback condition is met).
There was a problem hiding this comment.
sorry, just to clarify - if there were 10 shards, would it mean that all of them receive the trigger and only 1 executes?
There was a problem hiding this comment.
@mchain0 so where is the information on whether this shard is primary or backup? How does the engine know if it should subscribe to triggers but not execute?
CORA - Pending ReviewersAll codeowners have approved! ✅ Legend: ✅ Approved | ❌ Changes Requested | 💬 Commented | 🚫 Dismissed | ⏳ Pending | ❓ Unknown For more details, see the full review summary. |
…rdManualAssignment and Test_CRE_V2_ShardRingOCROverrides
|
| ShardOrchestratorAddress = '' # Default | ||
| # ShardAssignmentMode controls how workflows are assigned to shards. | ||
| # One of: "ringocr-only" (default), "manual-only", "ringocr-with-overrides". | ||
| ShardAssignmentMode = 'ringocr-only' # Default |
There was a problem hiding this comment.
This shouldn't be the default.
|
|
||
| switch { | ||
| case e.cfg.ShardResolver != nil: | ||
| shardID, found, resolveErr := e.cfg.ShardResolver.ResolveShard(ctx, e.cfg.WorkflowID, e.cfg.WorkflowOwner) |
There was a problem hiding this comment.
@mchain0 so where is the information on whether this shard is primary or backup? How does the engine know if it should subscribe to triggers but not execute?
4 participants
Enables manual shard assignments
owner->shard.Scope:
ShardAssignmentModefield added to[Sharding]TOML config with 3 mode constants (ringocr-only,manual-only,ringocr-with-overrides). Validation updated to skipShardOrchestratorAddressrequirement formanual-only.CRESettingsjob spec —config_typekey inside the existing settings TOML column branches between regular settings and shard assignment. No DB migration needed.validate.goparses and validates accordingly.delegate.goroutes to a dedicatedAtomicSettingsinstance for shard assignment, reusing the existingStore()pattern.ShardResolver(shardownership/resolver.go) — New interface with 3 implementations:ringOCRShardResolver— wraps ShardOrchestrator client (existing behavior)manualShardResolver— loads shard assignment TOML from AtomicSettings, parses it, O(1) owner→shard map lookup, no external depsoverrideShardResolver— manual wins for static owners, delegates to RingOCR for hashed ownerscre.gocreates the resolver based on mode.workflow_registry.go'sfilterWorkflowsBySharduses the resolver with owner hex fromWorkflowMetadataView.Owner. Engine execution guard uses the resolver withEngineConfig.WorkflowOwner.application.goskipsShardOrchestratorinfrastructure inmanual-onlymode.ShardAssignmentJobtype prependsconfig_type = "shard_assignment"to the settings TOML, reuses the existingcre-settings.tmpltemplate.ProposeShardAssignmentJoboperation added.Tests:
cre-4958