Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for increased steps based off of identifiers #1304

Merged
merged 2 commits into from
Apr 25, 2024
Merged

Conversation

tonyhb
Copy link
Contributor

@tonyhb tonyhb commented Apr 25, 2024

This allows customisation of step limits dependent on various factors in the identifier. Note that defaults do not change

Type of change (choose one)

  • Chore (refactors, upgrades, etc.)
  • Bug fix (non-breaking change that fixes an issue)
  • Security fix (non-breaking change that fixes a potential vulnerability)
  • Docs
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality not to work as expected)

Checklist

  • I've linked any associated issues to this PR.
  • I've tested my own changes.

Check our Pull Request Guidelines

Copy link

vercel bot commented Apr 25, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
ui ⬜️ Ignored (Inspect) Visit Preview Apr 25, 2024 8:45pm

This allows customisation of step limits dependent on various factors in
the identifier.  Note that defaults do not change
@@ -168,11 +168,8 @@ func WithLifecycleListeners(l ...execution.LifecycleListener) ExecutorOpt {
}
}

func WithStepLimits(limit uint) ExecutorOpt {
func WithStepLimits(limit func(id state.Identifier) int) ExecutorOpt {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be uint as well if the previous was an uint?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its mainly for types, so that we don't need to continue to typecast everywhere. we actively check for <= 0 in the validator so it's okay being an int, and is (i suppose) an easier type to work with.

@tonyhb tonyhb merged commit 312da2e into main Apr 25, 2024
12 checks passed
@tonyhb tonyhb deleted the feat/expanded-steps branch April 25, 2024 20:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants